<html><head><meta content="text/html; charset=UTF-8" http-equiv="content-type"><style type="text/css">.lst-kix_nmbh00m7ya3h-3>li:before{content:"\0025cf  "}.lst-kix_nmbh00m7ya3h-2>li:before{content:"\0025a0  "}.lst-kix_nmbh00m7ya3h-4>li:before{content:"\0025cb  "}.lst-kix_nmbh00m7ya3h-1>li:before{content:"\0025cb  "}.lst-kix_nmbh00m7ya3h-5>li:before{content:"\0025a0  "}.lst-kix_nmbh00m7ya3h-7>li:before{content:"\0025cb  "}ul.lst-kix_q3j1f64dhj6y-7{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-8{list-style-type:none}.lst-kix_nmbh00m7ya3h-0>li:before{content:"\0025cf  "}.lst-kix_nmbh00m7ya3h-6>li:before{content:"\0025cf  "}.lst-kix_nmbh00m7ya3h-8>li:before{content:"\0025a0  "}ul.lst-kix_q3j1f64dhj6y-3{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-4{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-5{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-6{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-0{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-1{list-style-type:none}ul.lst-kix_q3j1f64dhj6y-2{list-style-type:none}.lst-kix_vkohy0mjn19m-0>li:before{content:"+  "}.lst-kix_cz3d376cg0uh-0>li:before{content:"\0025cf  "}.lst-kix_cz3d376cg0uh-4>li:before{content:"\0025cb  "}.lst-kix_vkohy0mjn19m-5>li:before{content:"+  "}.lst-kix_vkohy0mjn19m-7>li:before{content:"+  "}.lst-kix_cz3d376cg0uh-2>li:before{content:"\0025a0  "}.lst-kix_cz3d376cg0uh-1>li:before{content:"\0025cb  "}.lst-kix_cz3d376cg0uh-5>li:before{content:"\0025a0  "}.lst-kix_vkohy0mjn19m-4>li:before{content:"+  "}.lst-kix_vkohy0mjn19m-8>li:before{content:"+  "}.lst-kix_vkohy0mjn19m-1>li:before{content:"+  "}.lst-kix_vkohy0mjn19m-3>li:before{content:"+  "}.lst-kix_cz3d376cg0uh-3>li:before{content:"\0025cf  "}.lst-kix_vkohy0mjn19m-2>li:before{content:"+  "}.lst-kix_cz3d376cg0uh-6>li:before{content:"\0025cf  "}.lst-kix_cz3d376cg0uh-8>li:before{content:"\0025a0  "}.lst-kix_cz3d376cg0uh-7>li:before{content:"\0025cb  "}.lst-kix_vkohy0mjn19m-6>li:before{content:"+  "}ul.lst-kix_bntp2tfkmlw3-8{list-style-type:none}.lst-kix_m106kfmnqwmr-0>li:before{content:"\0025cf  "}ul.lst-kix_bntp2tfkmlw3-7{list-style-type:none}ul.lst-kix_nf99afexz4qg-0{list-style-type:none}.lst-kix_m106kfmnqwmr-1>li:before{content:"\0025cb  "}.lst-kix_m106kfmnqwmr-3>li:before{content:"\0025cf  "}ul.lst-kix_hz8i7r30ijjn-0{list-style-type:none}.lst-kix_m106kfmnqwmr-2>li:before{content:"\0025a0  "}.lst-kix_pyp8natv44as-4>li:before{content:"\0025cb  "}.lst-kix_pyp8natv44as-3>li:before{content:"\0025cf  "}.lst-kix_pyp8natv44as-5>li:before{content:"\0025a0  "}.lst-kix_m106kfmnqwmr-5>li:before{content:"\0025a0  "}.lst-kix_m106kfmnqwmr-7>li:before{content:"\0025cb  "}.lst-kix_m106kfmnqwmr-4>li:before{content:"\0025cb  "}.lst-kix_m106kfmnqwmr-8>li:before{content:"\0025a0  "}.lst-kix_pyp8natv44as-0>li:before{content:"\0025cf  "}ul.lst-kix_bntp2tfkmlw3-6{list-style-type:none}ul.lst-kix_bntp2tfkmlw3-5{list-style-type:none}.lst-kix_pyp8natv44as-1>li:before{content:"\0025cb  "}ul.lst-kix_bntp2tfkmlw3-4{list-style-type:none}ul.lst-kix_bntp2tfkmlw3-3{list-style-type:none}.lst-kix_pyp8natv44as-2>li:before{content:"\0025a0  "}ul.lst-kix_bntp2tfkmlw3-2{list-style-type:none}ul.lst-kix_bntp2tfkmlw3-1{list-style-type:none}ul.lst-kix_bntp2tfkmlw3-0{list-style-type:none}.lst-kix_m106kfmnqwmr-6>li:before{content:"\0025cf  "}.lst-kix_bntp2tfkmlw3-5>li:before{content:"\0025a0  "}ul.lst-kix_nf99afexz4qg-7{list-style-type:none}ul.lst-kix_nf99afexz4qg-8{list-style-type:none}.lst-kix_bntp2tfkmlw3-3>li:before{content:"\0025cf  "}.lst-kix_bntp2tfkmlw3-4>li:before{content:"\0025cb  "}ul.lst-kix_nf99afexz4qg-5{list-style-type:none}ul.lst-kix_knxgn3f8infz-7{list-style-type:none}ul.lst-kix_nf99afexz4qg-6{list-style-type:none}ul.lst-kix_knxgn3f8infz-8{list-style-type:none}ul.lst-kix_nf99afexz4qg-3{list-style-type:none}ul.lst-kix_nf99afexz4qg-4{list-style-type:none}.lst-kix_bntp2tfkmlw3-2>li:before{content:"\0025a0  "}ul.lst-kix_nf99afexz4qg-1{list-style-type:none}ul.lst-kix_nf99afexz4qg-2{list-style-type:none}ul.lst-kix_knxgn3f8infz-1{list-style-type:none}ul.lst-kix_knxgn3f8infz-2{list-style-type:none}.lst-kix_bntp2tfkmlw3-0>li:before{content:"\0025cf  "}ul.lst-kix_knxgn3f8infz-0{list-style-type:none}ul.lst-kix_knxgn3f8infz-5{list-style-type:none}ul.lst-kix_knxgn3f8infz-6{list-style-type:none}.lst-kix_bntp2tfkmlw3-1>li:before{content:"\0025cb  "}ul.lst-kix_knxgn3f8infz-3{list-style-type:none}ul.lst-kix_knxgn3f8infz-4{list-style-type:none}.lst-kix_bntp2tfkmlw3-7>li:before{content:"\0025cb  "}.lst-kix_b02qw36i6z2v-1>li:before{content:"\0025cb  "}.lst-kix_l7i9i2n5it8l-7>li:before{content:"+  "}.lst-kix_pyp8natv44as-6>li:before{content:"\0025cf  "}.lst-kix_b02qw36i6z2v-3>li:before{content:"\0025cf  "}ul.lst-kix_hz8i7r30ijjn-2{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-1{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-4{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-3{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-6{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-5{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-8{list-style-type:none}ul.lst-kix_hz8i7r30ijjn-7{list-style-type:none}.lst-kix_pyp8natv44as-8>li:before{content:"\0025a0  "}.lst-kix_u2unz1dpmlhd-2>li:before{content:"\0025a0  "}.lst-kix_u2unz1dpmlhd-0>li:before{content:"\0025cf  "}.lst-kix_u2unz1dpmlhd-6>li:before{content:"\0025cf  "}.lst-kix_b02qw36i6z2v-5>li:before{content:"\0025a0  "}.lst-kix_b02qw36i6z2v-7>li:before{content:"\0025cb  "}.lst-kix_u2unz1dpmlhd-4>li:before{content:"\0025cb  "}.lst-kix_q3j1f64dhj6y-1>li:before{content:"\0025cb  "}.lst-kix_l7i9i2n5it8l-5>li:before{content:"+  "}.lst-kix_l7i9i2n5it8l-1>li:before{content:"+  "}.lst-kix_l7i9i2n5it8l-3>li:before{content:"+  "}.lst-kix_u2unz1dpmlhd-8>li:before{content:"\0025a0  "}.lst-kix_go2xi6t0lvgg-8>li:before{content:"\0025a0  "}.lst-kix_dmmvuob5kwxf-4>li:before{content:"\0025cb  "}.lst-kix_dmmvuob5kwxf-5>li:before{content:"\0025a0  "}.lst-kix_58jn7kl8qb33-1>li:before{content:"\0025cb  "}.lst-kix_58jn7kl8qb33-2>li:before{content:"\0025a0  "}.lst-kix_dmmvuob5kwxf-0>li:before{content:"\0025cf  "}.lst-kix_dmmvuob5kwxf-1>li:before{content:"\0025cb  "}.lst-kix_dmmvuob5kwxf-8>li:before{content:"\0025a0  "}.lst-kix_go2xi6t0lvgg-7>li:before{content:"\0025cb  "}.lst-kix_go2xi6t0lvgg-0>li:before{content:"\0025cf  "}.lst-kix_58jn7kl8qb33-6>li:before{content:"\0025cf  "}.lst-kix_go2xi6t0lvgg-4>li:before{content:"\0025cb  "}.lst-kix_58jn7kl8qb33-5>li:before{content:"\0025a0  "}.lst-kix_go2xi6t0lvgg-3>li:before{content:"\0025cf  "}.lst-kix_q3j1f64dhj6y-3>li:before{content:"\0025cf  "}.lst-kix_q3j1f64dhj6y-4>li:before{content:"\0025cb  "}.lst-kix_q3j1f64dhj6y-7>li:before{content:"\0025cb  "}.lst-kix_q3j1f64dhj6y-8>li:before{content:"\0025a0  "}.lst-kix_wt0va7c3wljs-6>li:before{content:"\0025cf  "}.lst-kix_wt0va7c3wljs-2>li:before{content:"\0025a0  "}.lst-kix_wt0va7c3wljs-3>li:before{content:"\0025cf  "}ul.lst-kix_xp6pikmusxhf-0{list-style-type:none}ul.lst-kix_xp6pikmusxhf-1{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-2{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-1{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-4{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-3{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-0{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-6{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-5{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-8{list-style-type:none}ul.lst-kix_u2unz1dpmlhd-7{list-style-type:none}.lst-kix_4x63s021cocj-3>li:before{content:"+  "}.lst-kix_4x63s021cocj-2>li:before{content:"+  "}.lst-kix_4x63s021cocj-7>li:before{content:"+  "}.lst-kix_4x63s021cocj-6>li:before{content:"+  "}.lst-kix_wt0va7c3wljs-7>li:before{content:"\0025cb  "}ul.lst-kix_fysp1ztzgb8r-4{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-3{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-2{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-1{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-0{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-8{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-7{list-style-type:none}ul.lst-kix_fysp1ztzgb8r-6{list-style-type:none}.lst-kix_lefaqjc90zys-0>li:before{content:"\0025cf  "}ul.lst-kix_fysp1ztzgb8r-5{list-style-type:none}ul.lst-kix_lq17pxt66ygq-6{list-style-type:none}ul.lst-kix_lq17pxt66ygq-5{list-style-type:none}ul.lst-kix_lq17pxt66ygq-4{list-style-type:none}.lst-kix_4yspfwn00mbq-2>li:before{content:"+  "}ul.lst-kix_lq17pxt66ygq-3{list-style-type:none}ul.lst-kix_lq17pxt66ygq-2{list-style-type:none}ul.lst-kix_lq17pxt66ygq-1{list-style-type:none}ul.lst-kix_lq17pxt66ygq-0{list-style-type:none}.lst-kix_bntp2tfkmlw3-8>li:before{content:"\0025a0  "}.lst-kix_4yspfwn00mbq-6>li:before{content:"+  "}ul.lst-kix_lq17pxt66ygq-8{list-style-type:none}.lst-kix_l7i9i2n5it8l-6>li:before{content:"+  "}ul.lst-kix_lq17pxt66ygq-7{list-style-type:none}ul.lst-kix_xp6pikmusxhf-6{list-style-type:none}ul.lst-kix_xp6pikmusxhf-7{list-style-type:none}ul.lst-kix_xp6pikmusxhf-8{list-style-type:none}.lst-kix_pyp8natv44as-7>li:before{content:"\0025cb  "}ul.lst-kix_xp6pikmusxhf-2{list-style-type:none}ul.lst-kix_xp6pikmusxhf-3{list-style-type:none}ul.lst-kix_xp6pikmusxhf-4{list-style-type:none}.lst-kix_b02qw36i6z2v-2>li:before{content:"\0025a0  "}ul.lst-kix_xp6pikmusxhf-5{list-style-type:none}.lst-kix_85s0agn6ebst-6>li:before{content:"\0025cf  "}.lst-kix_lefaqjc90zys-8>li:before{content:"\0025a0  "}.lst-kix_85s0agn6ebst-2>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-6>li:before{content:"\0025cf  "}.lst-kix_lefaqjc90zys-4>li:before{content:"\0025cb  "}ul.lst-kix_b02qw36i6z2v-3{list-style-type:none}ul.lst-kix_b02qw36i6z2v-4{list-style-type:none}ul.lst-kix_b02qw36i6z2v-1{list-style-type:none}ul.lst-kix_b02qw36i6z2v-2{list-style-type:none}.lst-kix_g7uvmsfgwgy7-1>li:before{content:"\0025cb  "}.lst-kix_g7uvmsfgwgy7-5>li:before{content:"\0025a0  "}ul.lst-kix_b02qw36i6z2v-0{list-style-type:none}ul.lst-kix_b02qw36i6z2v-7{list-style-type:none}ul.lst-kix_b02qw36i6z2v-8{list-style-type:none}ul.lst-kix_b02qw36i6z2v-5{list-style-type:none}.lst-kix_u2unz1dpmlhd-1>li:before{content:"\0025cb  "}ul.lst-kix_b02qw36i6z2v-6{list-style-type:none}.lst-kix_xglyqeugday7-1>li:before{content:"\0025cb  "}.lst-kix_b02qw36i6z2v-6>li:before{content:"\0025cf  "}.lst-kix_u2unz1dpmlhd-5>li:before{content:"\0025a0  "}.lst-kix_q3j1f64dhj6y-0>li:before{content:"\0025cf  "}.lst-kix_xdww37wt89zq-2>li:before{content:"\0025a0  "}.lst-kix_xdww37wt89zq-6>li:before{content:"\0025cf  "}.lst-kix_l7i9i2n5it8l-2>li:before{content:"+  "}ul.lst-kix_lr9db4ky8niv-0{list-style-type:none}ul.lst-kix_lr9db4ky8niv-1{list-style-type:none}ul.lst-kix_lr9db4ky8niv-2{list-style-type:none}ul.lst-kix_lr9db4ky8niv-3{list-style-type:none}ul.lst-kix_lr9db4ky8niv-4{list-style-type:none}ul.lst-kix_lr9db4ky8niv-5{list-style-type:none}ul.lst-kix_lr9db4ky8niv-6{list-style-type:none}ul.lst-kix_lr9db4ky8niv-7{list-style-type:none}ul.lst-kix_lr9db4ky8niv-8{list-style-type:none}.lst-kix_6ppucfqmpony-7>li:before{content:"\0025cb  "}.lst-kix_6ppucfqmpony-6>li:before{content:"\0025cf  "}.lst-kix_nf99afexz4qg-4>li:before{content:"\0025cb  "}.lst-kix_6ppucfqmpony-4>li:before{content:"\0025cb  "}.lst-kix_nf99afexz4qg-5>li:before{content:"\0025a0  "}ul.lst-kix_l7i9i2n5it8l-8{list-style-type:none}.lst-kix_nqbg3iecz3ej-6>li:before{content:"\0025cf  "}ul.lst-kix_l7i9i2n5it8l-7{list-style-type:none}.lst-kix_xglyqeugday7-8>li:before{content:"\0025a0  "}.lst-kix_knxgn3f8infz-0>li:before{content:"\0025cf  "}.lst-kix_nqbg3iecz3ej-3>li:before{content:"\0025cf  "}.lst-kix_nqbg3iecz3ej-1>li:before{content:"\0025cb  "}.lst-kix_nf99afexz4qg-7>li:before{content:"\0025cb  "}.lst-kix_knxgn3f8infz-3>li:before{content:"\0025cf  "}.lst-kix_nqbg3iecz3ej-0>li:before{content:"\0025cf  "}.lst-kix_nqbg3iecz3ej-8>li:before{content:"\0025a0  "}.lst-kix_6ppucfqmpony-1>li:before{content:"\0025cb  "}.lst-kix_xglyqeugday7-3>li:before{content:"\0025cf  "}.lst-kix_xglyqeugday7-6>li:before{content:"\0025cf  "}ul.lst-kix_l7i9i2n5it8l-2{list-style-type:none}ul.lst-kix_l7i9i2n5it8l-1{list-style-type:none}ul.lst-kix_l7i9i2n5it8l-0{list-style-type:none}.lst-kix_nf99afexz4qg-2>li:before{content:"\0025a0  "}ul.lst-kix_l7i9i2n5it8l-6{list-style-type:none}ul.lst-kix_l7i9i2n5it8l-5{list-style-type:none}ul.lst-kix_l7i9i2n5it8l-4{list-style-type:none}ul.lst-kix_l7i9i2n5it8l-3{list-style-type:none}ul.lst-kix_1zsvssxdqfab-6{list-style-type:none}ul.lst-kix_1zsvssxdqfab-5{list-style-type:none}ul.lst-kix_1zsvssxdqfab-4{list-style-type:none}ul.lst-kix_1zsvssxdqfab-3{list-style-type:none}ul.lst-kix_1zsvssxdqfab-8{list-style-type:none}ul.lst-kix_1zsvssxdqfab-7{list-style-type:none}.lst-kix_wpf36ljeh9si-2>li:before{content:"\0025a0  "}.lst-kix_e2ezhny2l7lp-0>li:before{content:"\0025cf  "}ul.lst-kix_85s0agn6ebst-1{list-style-type:none}.lst-kix_knxgn3f8infz-6>li:before{content:"\0025cf  "}ul.lst-kix_85s0agn6ebst-2{list-style-type:none}.lst-kix_knxgn3f8infz-5>li:before{content:"\0025a0  "}ul.lst-kix_85s0agn6ebst-0{list-style-type:none}.lst-kix_e2ezhny2l7lp-1>li:before{content:"\0025cb  "}.lst-kix_knxgn3f8infz-8>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-0>li:before{content:"\0025cf  "}ul.lst-kix_85s0agn6ebst-7{list-style-type:none}ul.lst-kix_85s0agn6ebst-8{list-style-type:none}.lst-kix_e2ezhny2l7lp-3>li:before{content:"\0025cf  "}ul.lst-kix_85s0agn6ebst-5{list-style-type:none}ul.lst-kix_1zsvssxdqfab-2{list-style-type:none}ul.lst-kix_85s0agn6ebst-6{list-style-type:none}ul.lst-kix_1zsvssxdqfab-1{list-style-type:none}ul.lst-kix_85s0agn6ebst-3{list-style-type:none}ul.lst-kix_1zsvssxdqfab-0{list-style-type:none}ul.lst-kix_85s0agn6ebst-4{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-5{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-6{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-7{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-8{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-1{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-2{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-3{list-style-type:none}ul.lst-kix_e2ezhny2l7lp-4{list-style-type:none}.lst-kix_e2ezhny2l7lp-6>li:before{content:"\0025cf  "}.lst-kix_e2ezhny2l7lp-8>li:before{content:"\0025a0  "}ul.lst-kix_e2ezhny2l7lp-0{list-style-type:none}.lst-kix_utl6c02hn3pj-3>li:before{content:"\0025cf  "}.lst-kix_utl6c02hn3pj-2>li:before{content:"\0025a0  "}.lst-kix_lefaqjc90zys-1>li:before{content:"\0025cb  "}.lst-kix_utl6c02hn3pj-0>li:before{content:"\0025cf  "}.lst-kix_utl6c02hn3pj-5>li:before{content:"\0025a0  "}ul.lst-kix_kuj44owq5q3t-8{list-style-type:none}ul.lst-kix_kuj44owq5q3t-7{list-style-type:none}.lst-kix_dkijbe2i5rcp-2>li:before{content:"\0025a0  "}ul.lst-kix_kuj44owq5q3t-4{list-style-type:none}ul.lst-kix_kuj44owq5q3t-3{list-style-type:none}ul.lst-kix_kuj44owq5q3t-6{list-style-type:none}.lst-kix_4yspfwn00mbq-3>li:before{content:"+  "}ul.lst-kix_kuj44owq5q3t-5{list-style-type:none}ul.lst-kix_kuj44owq5q3t-0{list-style-type:none}ul.lst-kix_kuj44owq5q3t-2{list-style-type:none}.lst-kix_dkijbe2i5rcp-0>li:before{content:"\0025cf  "}ul.lst-kix_kuj44owq5q3t-1{list-style-type:none}.lst-kix_4yspfwn00mbq-5>li:before{content:"+  "}.lst-kix_g1qhq0g47a57-6>li:before{content:"+  "}.lst-kix_v7y21dg74owg-7>li:before{content:"\0025cb  "}ul.lst-kix_lefaqjc90zys-1{list-style-type:none}.lst-kix_g1qhq0g47a57-4>li:before{content:"+  "}ul.lst-kix_lefaqjc90zys-0{list-style-type:none}.lst-kix_v7y21dg74owg-5>li:before{content:"\0025a0  "}ul.lst-kix_lefaqjc90zys-5{list-style-type:none}ul.lst-kix_lefaqjc90zys-4{list-style-type:none}ul.lst-kix_lefaqjc90zys-3{list-style-type:none}ul.lst-kix_lefaqjc90zys-2{list-style-type:none}ul.lst-kix_lefaqjc90zys-8{list-style-type:none}ul.lst-kix_lefaqjc90zys-7{list-style-type:none}ul.lst-kix_lefaqjc90zys-6{list-style-type:none}.lst-kix_85s0agn6ebst-3>li:before{content:"\0025cf  "}.lst-kix_vw67r1bqbxva-1>li:before{content:"\0025cb  "}.lst-kix_wpf36ljeh9si-3>li:before{content:"\0025cf  "}.lst-kix_85s0agn6ebst-5>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-5>li:before{content:"\0025a0  "}.lst-kix_dkijbe2i5rcp-8>li:before{content:"\0025a0  "}.lst-kix_lefaqjc90zys-3>li:before{content:"\0025cf  "}.lst-kix_vw67r1bqbxva-3>li:before{content:"\0025cf  "}.lst-kix_kuj44owq5q3t-2>li:before{content:"\0025a0  "}.lst-kix_xglyqeugday7-0>li:before{content:"\0025cf  "}.lst-kix_g7uvmsfgwgy7-0>li:before{content:"\0025cf  "}ul.lst-kix_v7y21dg74owg-6{list-style-type:none}.lst-kix_xdww37wt89zq-5>li:before{content:"\0025a0  "}ul.lst-kix_v7y21dg74owg-5{list-style-type:none}ul.lst-kix_v7y21dg74owg-8{list-style-type:none}ul.lst-kix_v7y21dg74owg-7{list-style-type:none}ul.lst-kix_v7y21dg74owg-2{list-style-type:none}ul.lst-kix_v7y21dg74owg-1{list-style-type:none}ul.lst-kix_v7y21dg74owg-4{list-style-type:none}ul.lst-kix_v7y21dg74owg-3{list-style-type:none}ul.lst-kix_v7y21dg74owg-0{list-style-type:none}.lst-kix_xdww37wt89zq-3>li:before{content:"\0025cf  "}ul.lst-kix_6ppucfqmpony-8{list-style-type:none}ul.lst-kix_6ppucfqmpony-7{list-style-type:none}ul.lst-kix_6ppucfqmpony-6{list-style-type:none}ul.lst-kix_6ppucfqmpony-5{list-style-type:none}ul.lst-kix_6ppucfqmpony-4{list-style-type:none}ul.lst-kix_6ppucfqmpony-3{list-style-type:none}ul.lst-kix_6ppucfqmpony-2{list-style-type:none}ul.lst-kix_6ppucfqmpony-1{list-style-type:none}ul.lst-kix_6ppucfqmpony-0{list-style-type:none}.lst-kix_g7uvmsfgwgy7-8>li:before{content:"\0025a0  "}.lst-kix_g7uvmsfgwgy7-6>li:before{content:"\0025cf  "}.lst-kix_krqcct51ae5g-8>li:before{content:"\0025a0  "}ul.lst-kix_4yspfwn00mbq-8{list-style-type:none}.lst-kix_go2xi6t0lvgg-6>li:before{content:"\0025cf  "}.lst-kix_dmmvuob5kwxf-7>li:before{content:"\0025cb  "}ul.lst-kix_4yspfwn00mbq-4{list-style-type:none}.lst-kix_krqcct51ae5g-3>li:before{content:"\0025cf  "}ul.lst-kix_4yspfwn00mbq-5{list-style-type:none}ul.lst-kix_4yspfwn00mbq-6{list-style-type:none}ul.lst-kix_4yspfwn00mbq-7{list-style-type:none}ul.lst-kix_4yspfwn00mbq-0{list-style-type:none}.lst-kix_hz8i7r30ijjn-0>li:before{content:"\0025cf  "}ul.lst-kix_4yspfwn00mbq-1{list-style-type:none}.lst-kix_dmmvuob5kwxf-2>li:before{content:"\0025a0  "}ul.lst-kix_4yspfwn00mbq-2{list-style-type:none}ul.lst-kix_4yspfwn00mbq-3{list-style-type:none}.lst-kix_58jn7kl8qb33-7>li:before{content:"\0025cb  "}.lst-kix_8uhoe6xj5uxp-1>li:before{content:"+  "}.lst-kix_go2xi6t0lvgg-1>li:before{content:"\0025cb  "}.lst-kix_58jn7kl8qb33-4>li:before{content:"\0025cb  "}.lst-kix_8uhoe6xj5uxp-4>li:before{content:"+  "}.lst-kix_xp6pikmusxhf-2>li:before{content:"\0025a0  "}.lst-kix_lr9db4ky8niv-7>li:before{content:"\0025cb  "}.lst-kix_q3j1f64dhj6y-6>li:before{content:"\0025cf  "}.lst-kix_hz8i7r30ijjn-8>li:before{content:"\0025a0  "}.lst-kix_krqcct51ae5g-0>li:before{content:"\0025cf  "}.lst-kix_hz8i7r30ijjn-3>li:before{content:"\0025cf  "}.lst-kix_kuj44owq5q3t-7>li:before{content:"\0025cb  "}.lst-kix_44bk24uu1uv5-0>li:before{content:"\0025cf  "}ul.lst-kix_xglyqeugday7-6{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-0{list-style-type:none}ul.lst-kix_xglyqeugday7-7{list-style-type:none}ul.lst-kix_xglyqeugday7-4{list-style-type:none}.lst-kix_wt0va7c3wljs-4>li:before{content:"\0025cb  "}ul.lst-kix_xglyqeugday7-5{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-3{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-4{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-1{list-style-type:none}.lst-kix_79jgx4uzqe5g-2>li:before{content:"\0025a0  "}ul.lst-kix_xglyqeugday7-8{list-style-type:none}.lst-kix_mkv0lsa0nly0-5>li:before{content:"-  "}ul.lst-kix_s4ykfd3t2gn3-2{list-style-type:none}.lst-kix_wt0va7c3wljs-1>li:before{content:"\0025cb  "}.lst-kix_xp6pikmusxhf-7>li:before{content:"\0025cb  "}ul.lst-kix_s4ykfd3t2gn3-7{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-8{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-5{list-style-type:none}ul.lst-kix_s4ykfd3t2gn3-6{list-style-type:none}.lst-kix_mkv0lsa0nly0-0>li:before{content:"-  "}ul.lst-kix_58jn7kl8qb33-0{list-style-type:none}ul.lst-kix_58jn7kl8qb33-6{list-style-type:none}ul.lst-kix_58jn7kl8qb33-5{list-style-type:none}ul.lst-kix_58jn7kl8qb33-8{list-style-type:none}ul.lst-kix_58jn7kl8qb33-7{list-style-type:none}ul.lst-kix_58jn7kl8qb33-2{list-style-type:none}.lst-kix_4x63s021cocj-1>li:before{content:"+  "}ul.lst-kix_58jn7kl8qb33-1{list-style-type:none}.lst-kix_s4ykfd3t2gn3-7>li:before{content:"\0025cb  "}.lst-kix_maqt99b0np5s-7>li:before{content:"\0025cb  "}ul.lst-kix_58jn7kl8qb33-4{list-style-type:none}ul.lst-kix_58jn7kl8qb33-3{list-style-type:none}.lst-kix_4x63s021cocj-4>li:before{content:"+  "}.lst-kix_maqt99b0np5s-2>li:before{content:"\0025a0  "}.lst-kix_79jgx4uzqe5g-5>li:before{content:"\0025a0  "}ul.lst-kix_xglyqeugday7-2{list-style-type:none}.lst-kix_mkv0lsa0nly0-8>li:before{content:"-  "}ul.lst-kix_xglyqeugday7-3{list-style-type:none}ul.lst-kix_xglyqeugday7-0{list-style-type:none}ul.lst-kix_xglyqeugday7-1{list-style-type:none}.lst-kix_4yspfwn00mbq-8>li:before{content:"+  "}.lst-kix_8iab95ppthik-5>li:before{content:"+  "}ul.lst-kix_8iab95ppthik-6{list-style-type:none}ul.lst-kix_8iab95ppthik-5{list-style-type:none}ul.lst-kix_8iab95ppthik-8{list-style-type:none}ul.lst-kix_8iab95ppthik-7{list-style-type:none}.lst-kix_utl6c02hn3pj-8>li:before{content:"\0025a0  "}ul.lst-kix_8iab95ppthik-2{list-style-type:none}ul.lst-kix_8iab95ppthik-1{list-style-type:none}.lst-kix_lq17pxt66ygq-2>li:before{content:"\0025a0  "}ul.lst-kix_8iab95ppthik-4{list-style-type:none}ul.lst-kix_8iab95ppthik-3{list-style-type:none}ul.lst-kix_8iab95ppthik-0{list-style-type:none}.lst-kix_b02qw36i6z2v-0>li:before{content:"\0025cf  "}.lst-kix_85s0agn6ebst-8>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-8>li:before{content:"\0025a0  "}.lst-kix_g1qhq0g47a57-1>li:before{content:"+  "}.lst-kix_4yspfwn00mbq-0>li:before{content:"+  "}.lst-kix_85s0agn6ebst-0>li:before{content:"\0025cf  "}.lst-kix_v7y21dg74owg-2>li:before{content:"\0025a0  "}.lst-kix_dkijbe2i5rcp-5>li:before{content:"\0025a0  "}.lst-kix_lefaqjc90zys-6>li:before{content:"\0025cf  "}.lst-kix_44aolqkom00p-4>li:before{content:"\0025cb  "}.lst-kix_g7uvmsfgwgy7-3>li:before{content:"\0025cf  "}.lst-kix_vw67r1bqbxva-6>li:before{content:"\0025cf  "}.lst-kix_b02qw36i6z2v-8>li:before{content:"\0025a0  "}.lst-kix_u2unz1dpmlhd-3>li:before{content:"\0025cf  "}.lst-kix_44bk24uu1uv5-8>li:before{content:"\0025a0  "}.lst-kix_xdww37wt89zq-8>li:before{content:"\0025a0  "}ul.lst-kix_xdww37wt89zq-4{list-style-type:none}ul.lst-kix_xdww37wt89zq-5{list-style-type:none}ul.lst-kix_xdww37wt89zq-6{list-style-type:none}ul.lst-kix_xdww37wt89zq-7{list-style-type:none}ul.lst-kix_xdww37wt89zq-8{list-style-type:none}.lst-kix_l7i9i2n5it8l-4>li:before{content:"+  "}ul.lst-kix_xdww37wt89zq-0{list-style-type:none}ul.lst-kix_xdww37wt89zq-1{list-style-type:none}ul.lst-kix_xdww37wt89zq-2{list-style-type:none}ul.lst-kix_xdww37wt89zq-3{list-style-type:none}.lst-kix_xdww37wt89zq-0>li:before{content:"\0025cf  "}ul.lst-kix_mkv0lsa0nly0-6{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-7{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-8{list-style-type:none}ul.lst-kix_vkohy0mjn19m-1{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-2{list-style-type:none}ul.lst-kix_vkohy0mjn19m-0{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-3{list-style-type:none}ul.lst-kix_vkohy0mjn19m-3{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-4{list-style-type:none}ul.lst-kix_vkohy0mjn19m-2{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-5{list-style-type:none}.lst-kix_fysp1ztzgb8r-1>li:before{content:"\0025cb  "}.lst-kix_y6nkyhcgp06z-0>li:before{content:"\0025cf  "}ul.lst-kix_vkohy0mjn19m-5{list-style-type:none}ul.lst-kix_vkohy0mjn19m-4{list-style-type:none}ul.lst-kix_vkohy0mjn19m-7{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-0{list-style-type:none}ul.lst-kix_vkohy0mjn19m-6{list-style-type:none}ul.lst-kix_mkv0lsa0nly0-1{list-style-type:none}.lst-kix_fysp1ztzgb8r-0>li:before{content:"\0025cf  "}.lst-kix_y6nkyhcgp06z-1>li:before{content:"\0025cb  "}.lst-kix_vyc1ggokfshl-5>li:before{content:"\0025a0  "}.lst-kix_vyc1ggokfshl-4>li:before{content:"\0025cb  "}.lst-kix_vyc1ggokfshl-6>li:before{content:"\0025cf  "}.lst-kix_fysp1ztzgb8r-3>li:before{content:"\0025cf  "}.lst-kix_fysp1ztzgb8r-5>li:before{content:"\0025a0  "}.lst-kix_y6nkyhcgp06z-2>li:before{content:"\0025a0  "}.lst-kix_y6nkyhcgp06z-4>li:before{content:"\0025cb  "}.lst-kix_po70c9achdsu-2>li:before{content:"\0025a0  "}.lst-kix_po70c9achdsu-3>li:before{content:"\0025cf  "}.lst-kix_fysp1ztzgb8r-2>li:before{content:"\0025a0  "}.lst-kix_fysp1ztzgb8r-6>li:before{content:"\0025cf  "}.lst-kix_y6nkyhcgp06z-3>li:before{content:"\0025cf  "}.lst-kix_y6nkyhcgp06z-7>li:before{content:"\0025cb  "}.lst-kix_po70c9achdsu-4>li:before{content:"\0025cb  "}.lst-kix_vyc1ggokfshl-8>li:before{content:"\0025a0  "}.lst-kix_y6nkyhcgp06z-6>li:before{content:"\0025cf  "}ul.lst-kix_wpf36ljeh9si-2{list-style-type:none}.lst-kix_vyc1ggokfshl-7>li:before{content:"\0025cb  "}ul.lst-kix_wpf36ljeh9si-1{list-style-type:none}ul.lst-kix_wpf36ljeh9si-0{list-style-type:none}.lst-kix_po70c9achdsu-5>li:before{content:"\0025a0  "}.lst-kix_fysp1ztzgb8r-4>li:before{content:"\0025cb  "}.lst-kix_y6nkyhcgp06z-5>li:before{content:"\0025a0  "}ul.lst-kix_wpf36ljeh9si-6{list-style-type:none}.lst-kix_po70c9achdsu-8>li:before{content:"\0025a0  "}ul.lst-kix_wpf36ljeh9si-5{list-style-type:none}ul.lst-kix_wpf36ljeh9si-4{list-style-type:none}ul.lst-kix_wpf36ljeh9si-3{list-style-type:none}.lst-kix_po70c9achdsu-6>li:before{content:"\0025cf  "}ul.lst-kix_wpf36ljeh9si-8{list-style-type:none}.lst-kix_po70c9achdsu-7>li:before{content:"\0025cb  "}ul.lst-kix_wpf36ljeh9si-7{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-0{list-style-type:none}.lst-kix_vyc1ggokfshl-2>li:before{content:"\0025a0  "}.lst-kix_y6nkyhcgp06z-8>li:before{content:"\0025a0  "}ul.lst-kix_dkijbe2i5rcp-2{list-style-type:none}.lst-kix_vyc1ggokfshl-3>li:before{content:"\0025cf  "}ul.lst-kix_dkijbe2i5rcp-1{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-4{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-3{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-6{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-5{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-8{list-style-type:none}ul.lst-kix_dkijbe2i5rcp-7{list-style-type:none}.lst-kix_vyc1ggokfshl-1>li:before{content:"\0025cb  "}.lst-kix_vyc1ggokfshl-0>li:before{content:"\0025cf  "}.lst-kix_1zsvssxdqfab-2>li:before{content:"\0025a0  "}.lst-kix_1zsvssxdqfab-3>li:before{content:"\0025cf  "}.lst-kix_1zsvssxdqfab-1>li:before{content:"\0025cb  "}.lst-kix_1zsvssxdqfab-0>li:before{content:"\0025cf  "}ul.lst-kix_krqcct51ae5g-8{list-style-type:none}ul.lst-kix_krqcct51ae5g-7{list-style-type:none}ul.lst-kix_krqcct51ae5g-6{list-style-type:none}ul.lst-kix_krqcct51ae5g-5{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-8{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-7{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-6{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-5{list-style-type:none}.lst-kix_po70c9achdsu-1>li:before{content:"\0025cb  "}.lst-kix_po70c9achdsu-0>li:before{content:"\0025cf  "}ul.lst-kix_krqcct51ae5g-4{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-0{list-style-type:none}ul.lst-kix_vkohy0mjn19m-8{list-style-type:none}ul.lst-kix_krqcct51ae5g-3{list-style-type:none}ul.lst-kix_krqcct51ae5g-2{list-style-type:none}ul.lst-kix_krqcct51ae5g-1{list-style-type:none}ul.lst-kix_krqcct51ae5g-0{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-4{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-3{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-2{list-style-type:none}ul.lst-kix_nmbh00m7ya3h-1{list-style-type:none}.lst-kix_lq17pxt66ygq-5>li:before{content:"\0025a0  "}.lst-kix_lq17pxt66ygq-3>li:before{content:"\0025cf  "}.lst-kix_lq17pxt66ygq-7>li:before{content:"\0025cb  "}.lst-kix_8iab95ppthik-8>li:before{content:"+  "}.lst-kix_44aolqkom00p-7>li:before{content:"\0025cb  "}.lst-kix_8iab95ppthik-2>li:before{content:"+  "}.lst-kix_8iab95ppthik-6>li:before{content:"+  "}.lst-kix_lq17pxt66ygq-1>li:before{content:"\0025cb  "}.lst-kix_8iab95ppthik-4>li:before{content:"+  "}.lst-kix_s4ykfd3t2gn3-2>li:before{content:"\0025a0  "}.lst-kix_s4ykfd3t2gn3-0>li:before{content:"\0025cf  "}.lst-kix_8iab95ppthik-0>li:before{content:"+  "}.lst-kix_44aolqkom00p-5>li:before{content:"\0025a0  "}.lst-kix_44aolqkom00p-1>li:before{content:"\0025cb  "}.lst-kix_44aolqkom00p-3>li:before{content:"\0025cf  "}.lst-kix_1zsvssxdqfab-4>li:before{content:"\0025cb  "}.lst-kix_1zsvssxdqfab-6>li:before{content:"\0025cf  "}.lst-kix_1zsvssxdqfab-8>li:before{content:"\0025a0  "}.lst-kix_44bk24uu1uv5-3>li:before{content:"\0025cf  "}ul.lst-kix_g1qhq0g47a57-2{list-style-type:none}.lst-kix_44bk24uu1uv5-5>li:before{content:"\0025a0  "}.lst-kix_lr9db4ky8niv-0>li:before{content:"\0025cf  "}ul.lst-kix_g1qhq0g47a57-3{list-style-type:none}ul.lst-kix_g1qhq0g47a57-0{list-style-type:none}ul.lst-kix_g1qhq0g47a57-1{list-style-type:none}ul.lst-kix_g1qhq0g47a57-6{list-style-type:none}ul.lst-kix_g1qhq0g47a57-7{list-style-type:none}ul.lst-kix_g1qhq0g47a57-4{list-style-type:none}ul.lst-kix_g1qhq0g47a57-5{list-style-type:none}.lst-kix_44bk24uu1uv5-7>li:before{content:"\0025cb  "}.lst-kix_lr9db4ky8niv-2>li:before{content:"\0025a0  "}ul.lst-kix_g1qhq0g47a57-8{list-style-type:none}.lst-kix_fysp1ztzgb8r-7>li:before{content:"\0025cb  "}.lst-kix_8uhoe6xj5uxp-6>li:before{content:"+  "}.lst-kix_8uhoe6xj5uxp-7>li:before{content:"+  "}.lst-kix_krqcct51ae5g-6>li:before{content:"\0025cf  "}ul.lst-kix_44bk24uu1uv5-0{list-style-type:none}ul.lst-kix_44bk24uu1uv5-1{list-style-type:none}ul.lst-kix_44bk24uu1uv5-2{list-style-type:none}.lst-kix_maqt99b0np5s-0>li:before{content:"\0025cf  "}.lst-kix_maqt99b0np5s-1>li:before{content:"\0025cb  "}.lst-kix_krqcct51ae5g-2>li:before{content:"\0025a0  "}.lst-kix_krqcct51ae5g-1>li:before{content:"\0025cb  "}.lst-kix_hz8i7r30ijjn-1>li:before{content:"\0025cb  "}ul.lst-kix_vw67r1bqbxva-8{list-style-type:none}ul.lst-kix_44bk24uu1uv5-3{list-style-type:none}ul.lst-kix_vw67r1bqbxva-4{list-style-type:none}ul.lst-kix_44bk24uu1uv5-4{list-style-type:none}ul.lst-kix_vw67r1bqbxva-5{list-style-type:none}.lst-kix_8uhoe6xj5uxp-2>li:before{content:"+  "}.lst-kix_8uhoe6xj5uxp-3>li:before{content:"+  "}ul.lst-kix_44bk24uu1uv5-5{list-style-type:none}ul.lst-kix_vw67r1bqbxva-6{list-style-type:none}ul.lst-kix_44bk24uu1uv5-6{list-style-type:none}ul.lst-kix_vw67r1bqbxva-7{list-style-type:none}ul.lst-kix_44bk24uu1uv5-7{list-style-type:none}ul.lst-kix_vw67r1bqbxva-0{list-style-type:none}.lst-kix_krqcct51ae5g-5>li:before{content:"\0025a0  "}ul.lst-kix_44bk24uu1uv5-8{list-style-type:none}ul.lst-kix_vw67r1bqbxva-1{list-style-type:none}ul.lst-kix_vw67r1bqbxva-2{list-style-type:none}ul.lst-kix_vw67r1bqbxva-3{list-style-type:none}.lst-kix_lr9db4ky8niv-8>li:before{content:"\0025a0  "}.lst-kix_xp6pikmusxhf-0>li:before{content:"\0025cf  "}.lst-kix_xp6pikmusxhf-4>li:before{content:"\0025cb  "}.lst-kix_lr9db4ky8niv-4>li:before{content:"\0025cb  "}.lst-kix_lr9db4ky8niv-5>li:before{content:"\0025a0  "}.lst-kix_xp6pikmusxhf-5>li:before{content:"\0025a0  "}.lst-kix_hz8i7r30ijjn-2>li:before{content:"\0025a0  "}.lst-kix_kuj44owq5q3t-8>li:before{content:"\0025a0  "}.lst-kix_hz8i7r30ijjn-6>li:before{content:"\0025cf  "}.lst-kix_kuj44owq5q3t-4>li:before{content:"\0025cb  "}.lst-kix_xp6pikmusxhf-1>li:before{content:"\0025cb  "}.lst-kix_hz8i7r30ijjn-5>li:before{content:"\0025a0  "}.lst-kix_kuj44owq5q3t-5>li:before{content:"\0025a0  "}.lst-kix_mkv0lsa0nly0-2>li:before{content:"-  "}.lst-kix_79jgx4uzqe5g-0>li:before{content:"\0025cf  "}.lst-kix_mkv0lsa0nly0-3>li:before{content:"-  "}.lst-kix_xp6pikmusxhf-8>li:before{content:"\0025a0  "}.lst-kix_s4ykfd3t2gn3-4>li:before{content:"\0025cb  "}.lst-kix_s4ykfd3t2gn3-5>li:before{content:"\0025a0  "}.lst-kix_maqt99b0np5s-8>li:before{content:"\0025a0  "}.lst-kix_79jgx4uzqe5g-8>li:before{content:"\0025a0  "}.lst-kix_79jgx4uzqe5g-7>li:before{content:"\0025cb  "}.lst-kix_maqt99b0np5s-4>li:before{content:"\0025cb  "}.lst-kix_maqt99b0np5s-5>li:before{content:"\0025a0  "}.lst-kix_s4ykfd3t2gn3-8>li:before{content:"\0025a0  "}.lst-kix_79jgx4uzqe5g-3>li:before{content:"\0025cf  "}.lst-kix_mkv0lsa0nly0-6>li:before{content:"-  "}.lst-kix_79jgx4uzqe5g-4>li:before{content:"\0025cb  "}.lst-kix_mkv0lsa0nly0-7>li:before{content:"-  "}.lst-kix_lq17pxt66ygq-4>li:before{content:"\0025cb  "}.lst-kix_lq17pxt66ygq-8>li:before{content:"\0025a0  "}ul.lst-kix_utl6c02hn3pj-0{list-style-type:none}ul.lst-kix_utl6c02hn3pj-1{list-style-type:none}.lst-kix_8iab95ppthik-7>li:before{content:"+  "}ul.lst-kix_utl6c02hn3pj-4{list-style-type:none}ul.lst-kix_utl6c02hn3pj-5{list-style-type:none}ul.lst-kix_utl6c02hn3pj-2{list-style-type:none}.lst-kix_dkijbe2i5rcp-3>li:before{content:"\0025cf  "}ul.lst-kix_utl6c02hn3pj-3{list-style-type:none}.lst-kix_utl6c02hn3pj-6>li:before{content:"\0025cf  "}ul.lst-kix_79jgx4uzqe5g-2{list-style-type:none}ul.lst-kix_utl6c02hn3pj-8{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-1{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-0{list-style-type:none}ul.lst-kix_utl6c02hn3pj-6{list-style-type:none}.lst-kix_8iab95ppthik-3>li:before{content:"+  "}ul.lst-kix_utl6c02hn3pj-7{list-style-type:none}.lst-kix_lq17pxt66ygq-0>li:before{content:"\0025cf  "}ul.lst-kix_44aolqkom00p-1{list-style-type:none}ul.lst-kix_44aolqkom00p-2{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-8{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-7{list-style-type:none}ul.lst-kix_44aolqkom00p-0{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-6{list-style-type:none}ul.lst-kix_44aolqkom00p-5{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-5{list-style-type:none}ul.lst-kix_44aolqkom00p-6{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-4{list-style-type:none}ul.lst-kix_44aolqkom00p-3{list-style-type:none}ul.lst-kix_79jgx4uzqe5g-3{list-style-type:none}.lst-kix_v7y21dg74owg-8>li:before{content:"\0025a0  "}ul.lst-kix_44aolqkom00p-4{list-style-type:none}.lst-kix_s4ykfd3t2gn3-1>li:before{content:"\0025cb  "}ul.lst-kix_44aolqkom00p-7{list-style-type:none}.lst-kix_g1qhq0g47a57-7>li:before{content:"+  "}ul.lst-kix_44aolqkom00p-8{list-style-type:none}.lst-kix_g1qhq0g47a57-3>li:before{content:"+  "}.lst-kix_vw67r1bqbxva-0>li:before{content:"\0025cf  "}.lst-kix_v7y21dg74owg-4>li:before{content:"\0025cb  "}.lst-kix_44aolqkom00p-6>li:before{content:"\0025cf  "}ul.lst-kix_pyp8natv44as-0{list-style-type:none}ul.lst-kix_pyp8natv44as-1{list-style-type:none}ul.lst-kix_pyp8natv44as-2{list-style-type:none}ul.lst-kix_pyp8natv44as-3{list-style-type:none}ul.lst-kix_pyp8natv44as-4{list-style-type:none}ul.lst-kix_pyp8natv44as-5{list-style-type:none}ul.lst-kix_pyp8natv44as-6{list-style-type:none}ul.lst-kix_pyp8natv44as-7{list-style-type:none}.lst-kix_vw67r1bqbxva-4>li:before{content:"\0025cb  "}.lst-kix_v7y21dg74owg-0>li:before{content:"\0025cf  "}.lst-kix_dkijbe2i5rcp-7>li:before{content:"\0025cb  "}ul.lst-kix_pyp8natv44as-8{list-style-type:none}.lst-kix_44aolqkom00p-2>li:before{content:"\0025a0  "}.lst-kix_44bk24uu1uv5-2>li:before{content:"\0025a0  "}.lst-kix_vw67r1bqbxva-8>li:before{content:"\0025a0  "}.lst-kix_kuj44owq5q3t-1>li:before{content:"\0025cb  "}.lst-kix_1zsvssxdqfab-7>li:before{content:"\0025cb  "}.lst-kix_44bk24uu1uv5-6>li:before{content:"\0025cf  "}.lst-kix_lr9db4ky8niv-1>li:before{content:"\0025cb  "}.lst-kix_fysp1ztzgb8r-8>li:before{content:"\0025a0  "}ul.lst-kix_8uhoe6xj5uxp-1{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-0{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-8{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-3{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-2{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-1{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-0{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-7{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-6{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-5{list-style-type:none}ul.lst-kix_y6nkyhcgp06z-4{list-style-type:none}.lst-kix_nf99afexz4qg-8>li:before{content:"\0025a0  "}.lst-kix_6ppucfqmpony-5>li:before{content:"\0025a0  "}.lst-kix_nqbg3iecz3ej-5>li:before{content:"\0025a0  "}ul.lst-kix_maqt99b0np5s-8{list-style-type:none}.lst-kix_6ppucfqmpony-3>li:before{content:"\0025cf  "}.lst-kix_nf99afexz4qg-3>li:before{content:"\0025cf  "}.lst-kix_nqbg3iecz3ej-4>li:before{content:"\0025cb  "}ul.lst-kix_maqt99b0np5s-5{list-style-type:none}.lst-kix_nqbg3iecz3ej-7>li:before{content:"\0025cb  "}ul.lst-kix_maqt99b0np5s-4{list-style-type:none}ul.lst-kix_maqt99b0np5s-7{list-style-type:none}ul.lst-kix_maqt99b0np5s-6{list-style-type:none}ul.lst-kix_maqt99b0np5s-1{list-style-type:none}.lst-kix_knxgn3f8infz-2>li:before{content:"\0025a0  "}ul.lst-kix_maqt99b0np5s-0{list-style-type:none}.lst-kix_6ppucfqmpony-0>li:before{content:"\0025cf  "}ul.lst-kix_maqt99b0np5s-3{list-style-type:none}.lst-kix_knxgn3f8infz-1>li:before{content:"\0025cb  "}.lst-kix_nqbg3iecz3ej-2>li:before{content:"\0025a0  "}ul.lst-kix_maqt99b0np5s-2{list-style-type:none}.lst-kix_nf99afexz4qg-6>li:before{content:"\0025cf  "}.lst-kix_6ppucfqmpony-2>li:before{content:"\0025a0  "}.lst-kix_xglyqeugday7-4>li:before{content:"\0025cb  "}.lst-kix_nf99afexz4qg-0>li:before{content:"\0025cf  "}ul.lst-kix_8uhoe6xj5uxp-8{list-style-type:none}.lst-kix_nf99afexz4qg-1>li:before{content:"\0025cb  "}.lst-kix_xglyqeugday7-5>li:before{content:"\0025a0  "}.lst-kix_xglyqeugday7-7>li:before{content:"\0025cb  "}ul.lst-kix_8uhoe6xj5uxp-7{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-6{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-5{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-4{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-3{list-style-type:none}ul.lst-kix_8uhoe6xj5uxp-2{list-style-type:none}ul.lst-kix_4x63s021cocj-3{list-style-type:none}ul.lst-kix_4x63s021cocj-4{list-style-type:none}ul.lst-kix_4x63s021cocj-1{list-style-type:none}ul.lst-kix_4x63s021cocj-2{list-style-type:none}ul.lst-kix_4x63s021cocj-7{list-style-type:none}ul.lst-kix_4x63s021cocj-8{list-style-type:none}ul.lst-kix_4x63s021cocj-5{list-style-type:none}ul.lst-kix_4x63s021cocj-6{list-style-type:none}ul.lst-kix_cz3d376cg0uh-8{list-style-type:none}.lst-kix_knxgn3f8infz-7>li:before{content:"\0025cb  "}.lst-kix_wpf36ljeh9si-1>li:before{content:"\0025cb  "}ul.lst-kix_cz3d376cg0uh-4{list-style-type:none}.lst-kix_knxgn3f8infz-4>li:before{content:"\0025cb  "}ul.lst-kix_cz3d376cg0uh-5{list-style-type:none}ul.lst-kix_4x63s021cocj-0{list-style-type:none}ul.lst-kix_cz3d376cg0uh-6{list-style-type:none}ul.lst-kix_cz3d376cg0uh-7{list-style-type:none}.lst-kix_e2ezhny2l7lp-2>li:before{content:"\0025a0  "}ul.lst-kix_cz3d376cg0uh-0{list-style-type:none}ul.lst-kix_cz3d376cg0uh-1{list-style-type:none}ul.lst-kix_cz3d376cg0uh-2{list-style-type:none}ul.lst-kix_cz3d376cg0uh-3{list-style-type:none}.lst-kix_e2ezhny2l7lp-5>li:before{content:"\0025a0  "}.lst-kix_e2ezhny2l7lp-4>li:before{content:"\0025cb  "}.lst-kix_e2ezhny2l7lp-7>li:before{content:"\0025cb  "}.lst-kix_6ppucfqmpony-8>li:before{content:"\0025a0  "}ul.lst-kix_m106kfmnqwmr-8{list-style-type:none}.lst-kix_utl6c02hn3pj-4>li:before{content:"\0025cb  "}ul.lst-kix_m106kfmnqwmr-0{list-style-type:none}ul.lst-kix_m106kfmnqwmr-1{list-style-type:none}ul.lst-kix_m106kfmnqwmr-2{list-style-type:none}ul.lst-kix_m106kfmnqwmr-3{list-style-type:none}ul.lst-kix_m106kfmnqwmr-4{list-style-type:none}ul.lst-kix_m106kfmnqwmr-5{list-style-type:none}ul.lst-kix_m106kfmnqwmr-6{list-style-type:none}ul.lst-kix_m106kfmnqwmr-7{list-style-type:none}.lst-kix_utl6c02hn3pj-7>li:before{content:"\0025cb  "}.lst-kix_4yspfwn00mbq-7>li:before{content:"+  "}.lst-kix_g1qhq0g47a57-8>li:before{content:"+  "}ul.lst-kix_nqbg3iecz3ej-7{list-style-type:none}.lst-kix_g1qhq0g47a57-2>li:before{content:"+  "}ul.lst-kix_nqbg3iecz3ej-8{list-style-type:none}.lst-kix_85s0agn6ebst-7>li:before{content:"\0025cb  "}.lst-kix_4yspfwn00mbq-1>li:before{content:"+  "}.lst-kix_v7y21dg74owg-1>li:before{content:"\0025cb  "}.lst-kix_dkijbe2i5rcp-4>li:before{content:"\0025cb  "}.lst-kix_lefaqjc90zys-7>li:before{content:"\0025cb  "}.lst-kix_85s0agn6ebst-1>li:before{content:"\0025cb  "}.lst-kix_v7y21dg74owg-3>li:before{content:"\0025cf  "}.lst-kix_vw67r1bqbxva-5>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-7>li:before{content:"\0025cb  "}.lst-kix_dkijbe2i5rcp-6>li:before{content:"\0025cf  "}.lst-kix_lefaqjc90zys-5>li:before{content:"\0025a0  "}.lst-kix_g7uvmsfgwgy7-4>li:before{content:"\0025cb  "}.lst-kix_kuj44owq5q3t-0>li:before{content:"\0025cf  "}.lst-kix_vw67r1bqbxva-7>li:before{content:"\0025cb  "}.lst-kix_g7uvmsfgwgy7-2>li:before{content:"\0025a0  "}ul.lst-kix_dmmvuob5kwxf-8{list-style-type:none}.lst-kix_xglyqeugday7-2>li:before{content:"\0025a0  "}ul.lst-kix_wt0va7c3wljs-8{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-0{list-style-type:none}ul.lst-kix_wt0va7c3wljs-7{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-1{list-style-type:none}ul.lst-kix_wt0va7c3wljs-6{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-2{list-style-type:none}ul.lst-kix_wt0va7c3wljs-5{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-3{list-style-type:none}.lst-kix_g1qhq0g47a57-0>li:before{content:"+  "}ul.lst-kix_wt0va7c3wljs-4{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-4{list-style-type:none}ul.lst-kix_wt0va7c3wljs-3{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-5{list-style-type:none}ul.lst-kix_wt0va7c3wljs-2{list-style-type:none}ul.lst-kix_nqbg3iecz3ej-6{list-style-type:none}ul.lst-kix_wt0va7c3wljs-1{list-style-type:none}ul.lst-kix_wt0va7c3wljs-0{list-style-type:none}.lst-kix_xdww37wt89zq-7>li:before{content:"\0025cb  "}ul.lst-kix_dmmvuob5kwxf-0{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-1{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-2{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-3{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-4{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-5{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-6{list-style-type:none}ul.lst-kix_dmmvuob5kwxf-7{list-style-type:none}.lst-kix_xdww37wt89zq-1>li:before{content:"\0025cb  "}.lst-kix_58jn7kl8qb33-0>li:before{content:"\0025cf  "}.lst-kix_krqcct51ae5g-7>li:before{content:"\0025cb  "}ul.lst-kix_g7uvmsfgwgy7-7{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-8{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-5{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-6{list-style-type:none}.lst-kix_dmmvuob5kwxf-3>li:before{content:"\0025cf  "}.lst-kix_8uhoe6xj5uxp-5>li:before{content:"+  "}ul.lst-kix_g7uvmsfgwgy7-3{list-style-type:none}.lst-kix_go2xi6t0lvgg-5>li:before{content:"\0025a0  "}ul.lst-kix_g7uvmsfgwgy7-4{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-1{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-2{list-style-type:none}ul.lst-kix_g7uvmsfgwgy7-0{list-style-type:none}.lst-kix_8uhoe6xj5uxp-0>li:before{content:"+  "}.lst-kix_8uhoe6xj5uxp-8>li:before{content:"+  "}.lst-kix_go2xi6t0lvgg-2>li:before{content:"\0025a0  "}.lst-kix_58jn7kl8qb33-3>li:before{content:"\0025cf  "}.lst-kix_krqcct51ae5g-4>li:before{content:"\0025cb  "}.lst-kix_dmmvuob5kwxf-6>li:before{content:"\0025cf  "}ul.lst-kix_po70c9achdsu-4{list-style-type:none}ul.lst-kix_po70c9achdsu-3{list-style-type:none}.lst-kix_q3j1f64dhj6y-2>li:before{content:"\0025a0  "}ul.lst-kix_po70c9achdsu-6{list-style-type:none}ul.lst-kix_po70c9achdsu-5{list-style-type:none}ul.lst-kix_po70c9achdsu-8{list-style-type:none}ul.lst-kix_po70c9achdsu-7{list-style-type:none}.lst-kix_xp6pikmusxhf-3>li:before{content:"\0025cf  "}.lst-kix_hz8i7r30ijjn-7>li:before{content:"\0025cb  "}.lst-kix_xp6pikmusxhf-6>li:before{content:"\0025cf  "}.lst-kix_q3j1f64dhj6y-5>li:before{content:"\0025a0  "}.lst-kix_lr9db4ky8niv-6>li:before{content:"\0025cf  "}.lst-kix_44bk24uu1uv5-1>li:before{content:"\0025cb  "}.lst-kix_kuj44owq5q3t-6>li:before{content:"\0025cf  "}ul.lst-kix_po70c9achdsu-0{list-style-type:none}.lst-kix_hz8i7r30ijjn-4>li:before{content:"\0025cb  "}ul.lst-kix_po70c9achdsu-2{list-style-type:none}ul.lst-kix_po70c9achdsu-1{list-style-type:none}.lst-kix_wt0va7c3wljs-5>li:before{content:"\0025a0  "}.lst-kix_mkv0lsa0nly0-1>li:before{content:"-  "}ul.lst-kix_go2xi6t0lvgg-8{list-style-type:none}ul.lst-kix_vyc1ggokfshl-3{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-7{list-style-type:none}ul.lst-kix_vyc1ggokfshl-4{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-6{list-style-type:none}ul.lst-kix_vyc1ggokfshl-5{list-style-type:none}.lst-kix_4x63s021cocj-8>li:before{content:"+  "}ul.lst-kix_go2xi6t0lvgg-5{list-style-type:none}ul.lst-kix_vyc1ggokfshl-6{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-4{list-style-type:none}.lst-kix_79jgx4uzqe5g-1>li:before{content:"\0025cb  "}ul.lst-kix_vyc1ggokfshl-7{list-style-type:none}.lst-kix_mkv0lsa0nly0-4>li:before{content:"-  "}ul.lst-kix_go2xi6t0lvgg-3{list-style-type:none}ul.lst-kix_vyc1ggokfshl-8{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-2{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-1{list-style-type:none}ul.lst-kix_go2xi6t0lvgg-0{list-style-type:none}.lst-kix_wt0va7c3wljs-0>li:before{content:"\0025cf  "}.lst-kix_s4ykfd3t2gn3-6>li:before{content:"\0025cf  "}.lst-kix_4x63s021cocj-0>li:before{content:"+  "}.lst-kix_58jn7kl8qb33-8>li:before{content:"\0025a0  "}.lst-kix_maqt99b0np5s-6>li:before{content:"\0025cf  "}ul.lst-kix_vyc1ggokfshl-0{list-style-type:none}.lst-kix_79jgx4uzqe5g-6>li:before{content:"\0025cf  "}ul.lst-kix_vyc1ggokfshl-1{list-style-type:none}ul.lst-kix_vyc1ggokfshl-2{list-style-type:none}.lst-kix_wt0va7c3wljs-8>li:before{content:"\0025a0  "}.lst-kix_4x63s021cocj-5>li:before{content:"+  "}.lst-kix_maqt99b0np5s-3>li:before{content:"\0025cf  "}.lst-kix_lq17pxt66ygq-6>li:before{content:"\0025cf  "}.lst-kix_utl6c02hn3pj-1>li:before{content:"\0025cb  "}.lst-kix_lefaqjc90zys-2>li:before{content:"\0025a0  "}.lst-kix_4yspfwn00mbq-4>li:before{content:"+  "}.lst-kix_bntp2tfkmlw3-6>li:before{content:"\0025cf  "}.lst-kix_dkijbe2i5rcp-1>li:before{content:"\0025cb  "}.lst-kix_44aolqkom00p-8>li:before{content:"\0025a0  "}.lst-kix_s4ykfd3t2gn3-3>li:before{content:"\0025cf  "}.lst-kix_g1qhq0g47a57-5>li:before{content:"+  "}.lst-kix_b02qw36i6z2v-4>li:before{content:"\0025cb  "}.lst-kix_v7y21dg74owg-6>li:before{content:"\0025cf  "}.lst-kix_44aolqkom00p-0>li:before{content:"\0025cf  "}.lst-kix_l7i9i2n5it8l-8>li:before{content:"+  "}.lst-kix_8iab95ppthik-1>li:before{content:"+  "}.lst-kix_85s0agn6ebst-4>li:before{content:"\0025cb  "}.lst-kix_vw67r1bqbxva-2>li:before{content:"\0025a0  "}.lst-kix_wpf36ljeh9si-4>li:before{content:"\0025cb  "}.lst-kix_kuj44owq5q3t-3>li:before{content:"\0025cf  "}.lst-kix_1zsvssxdqfab-5>li:before{content:"\0025a0  "}.lst-kix_44bk24uu1uv5-4>li:before{content:"\0025cb  "}.lst-kix_u2unz1dpmlhd-7>li:before{content:"\0025cb  "}.lst-kix_lr9db4ky8niv-3>li:before{content:"\0025cf  "}.lst-kix_xdww37wt89zq-4>li:before{content:"\0025cb  "}.lst-kix_l7i9i2n5it8l-0>li:before{content:"+  "}.lst-kix_g7uvmsfgwgy7-7>li:before{content:"\0025cb  "}ol{margin:0;padding:0}table td,table th{padding:0}.c18{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#b6d7a8;border-left-style:solid;border-bottom-width:1pt;width:63pt;border-top-color:#000000;border-bottom-style:solid}.c22{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#999999;border-left-style:solid;border-bottom-width:1pt;width:63pt;border-top-color:#000000;border-bottom-style:solid}.c12{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#f3f3f3;border-left-style:solid;border-bottom-width:1pt;width:63pt;border-top-color:#000000;border-bottom-style:solid}.c20{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#999999;border-left-style:solid;border-bottom-width:1pt;width:352.5pt;border-top-color:#000000;border-bottom-style:solid}.c35{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;background-color:#f3f3f3;border-left-style:solid;border-bottom-width:1pt;width:468pt;border-top-color:#000000;border-bottom-style:solid}.c21{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:51.8pt;border-top-color:#000000;border-bottom-style:solid}.c26{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:352.5pt;border-top-color:#000000;border-bottom-style:solid}.c2{margin-left:36pt;padding-top:0pt;padding-left:0pt;padding-bottom:0pt;line-height:1.15;orphans:2;widows:2;text-align:left}.c47{-webkit-text-decoration-skip:none;color:#000000;font-weight:400;text-decoration:underline;vertical-align:baseline;text-decoration-skip-ink:none;font-family:"Arial";font-style:normal}.c5{padding-top:16pt;padding-bottom:4pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c24{color:#434343;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:14pt;font-family:"Arial";font-style:normal}.c48{padding-top:0pt;padding-bottom:3pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c27{margin-left:18pt;padding-top:3pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c3{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.c39{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:20pt;font-family:"Arial";font-style:normal}.c16{padding-top:18pt;padding-bottom:6pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c10{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:16pt;font-family:"Arial";font-style:normal}.c42{padding-top:20pt;padding-bottom:6pt;line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.c0{color:#000000;font-weight:700;text-decoration:none;vertical-align:baseline;font-size:9pt;font-family:"Arial";font-style:normal}.c51{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial"}.c37{color:#000000;text-decoration:none;vertical-align:baseline;font-size:26pt;font-family:"Arial";font-style:normal}.c17{color:#000000;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.c6{margin-left:36pt;padding-top:0pt;padding-left:0pt;padding-bottom:0pt;line-height:1.0;text-align:left}.c41{padding-top:4pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c44{padding-top:10pt;padding-bottom:4pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c38{padding-top:12pt;padding-bottom:12pt;line-height:1.15;orphans:2;widows:2;text-align:left}.c49{padding-top:0pt;padding-bottom:0pt;line-height:1.15;orphans:2;widows:2;text-align:justify}.c36{padding-top:10pt;padding-bottom:0pt;line-height:1.0;orphans:2;widows:2;text-align:left}.c9{padding-top:0pt;padding-bottom:0pt;line-height:1.15;orphans:2;widows:2;text-align:left}.c23{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:left;height:11pt}.c45{text-decoration:none;vertical-align:baseline;font-size:20pt;font-family:"Arial";font-style:normal}.c8{padding-top:16pt;padding-bottom:4pt;line-height:1.0;page-break-after:avoid;text-align:left}.c31{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:left}.c43{border-spacing:0;border-collapse:collapse;margin-right:auto}.c11{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}.c19{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:center}.c52{background-color:#ffffff;max-width:468pt;padding:72pt 72pt 72pt 72pt}.c7{padding:0;margin:0}.c46{margin-left:36pt;padding-left:0pt}.c13{margin-left:108pt;padding-left:0pt}.c50{border:1px solid black;margin:5px}.c4{color:inherit;text-decoration:inherit}.c15{margin-left:72pt;padding-left:0pt}.c30{height:11pt}.c40{background-color:#999999}.c1{font-weight:700}.c28{font-size:9pt}.c14{height:0pt}.c32{height:25.8pt}.c29{font-style:italic}.c25{font-size:15pt}.c33{background-color:#b6d7a8}.c34{color:#1155cc}.title{padding-top:0pt;color:#000000;font-size:26pt;padding-bottom:3pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}.subtitle{padding-top:0pt;color:#666666;font-size:15pt;padding-bottom:16pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}li{color:#000000;font-size:11pt;font-family:"Arial"}p{margin:0;color:#000000;font-size:11pt;font-family:"Arial"}h1{padding-top:20pt;color:#000000;font-size:20pt;padding-bottom:6pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h2{padding-top:18pt;color:#000000;font-size:16pt;padding-bottom:6pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h3{padding-top:16pt;color:#434343;font-size:14pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h4{padding-top:14pt;color:#666666;font-size:12pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h5{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;orphans:2;widows:2;text-align:left}h6{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.15;page-break-after:avoid;font-style:italic;orphans:2;widows:2;text-align:left}</style></head><body class="c52"><div><p class="c9 c30"><span class="c3"></span></p></div><p class="c48 title" id="h.odc700in1ypg"><span class="c1 c37">WebPerf WG @ TPAC 2020</span></p><p class="c9"><span class="c11 c25"><a class="c4" href="https://www.google.com/url?q=https://bit.ly/webperf-tpac20&amp;sa=D&amp;ust=1607595378176000&amp;usg=AOvVaw3WuEPo1PoJM5vaO3pHgvGY">bit.ly/webperf-tpac20</a></span></p><p class="c9 c30"><span class="c3"></span></p><a id="t.a4d217188b2272cacee06964bfd17e9ebfd3d6e8"></a><a id="t.0"></a><table class="c43"><tbody><tr class="c14"><td class="c35" colspan="1" rowspan="1"><p class="c23"><span class="c3"></span></p><p class="c41"><span class="c1"><a class="c4" href="#h.wlg3h8rzf61l">Logistics</a></span><span class="c1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c1"><a class="c4" href="#h.wlg3h8rzf61l">1</a></span></p><p class="c27"><span><a class="c4" href="#h.dblx6emzzv04">Location &amp; participation</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c4" href="#h.dblx6emzzv04">1</a></span></p><p class="c27"><span><a class="c4" href="#h.x2o0mg51zqnv">Attendees</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c4" href="#h.x2o0mg51zqnv">1</a></span></p><p class="c36"><span class="c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1-xMvUHAjqhQdegNqupxlqsLbfPHWq5MJ0iySg9Z1KBs/edit%23heading%3Dh.lnthn2y6jgo8&amp;sa=D&amp;ust=1607595378179000&amp;usg=AOvVaw3xQnpRnRLkx0-0Ix13uNUG">Agenda scratchpad</a></span><span class="c1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1-xMvUHAjqhQdegNqupxlqsLbfPHWq5MJ0iySg9Z1KBs/edit%23heading%3Dh.lnthn2y6jgo8&amp;sa=D&amp;ust=1607595378179000&amp;usg=AOvVaw3xQnpRnRLkx0-0Ix13uNUG">1</a></span></p><p class="c36"><span class="c1"><a class="c4" href="#h.tx59951gswac">Agenda</a></span><span class="c1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c1"><a class="c4" href="#h.tx59951gswac">2</a></span></p><p class="c27"><span><a class="c4" href="#h.k0zzrh9ez9fv">Monday</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c4" href="#h.k0zzrh9ez9fv">2</a></span></p><p class="c27"><span><a class="c4" href="#h.e2nehhjf0s82">Tuesday</a></span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span><a class="c4" href="#h.e2nehhjf0s82">2</a></span></p><p class="c44"><span class="c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1-xMvUHAjqhQdegNqupxlqsLbfPHWq5MJ0iySg9Z1KBs/edit%23heading%3Dh.ym9i2k8eaxr5&amp;sa=D&amp;ust=1607595378181000&amp;usg=AOvVaw0ZrXSod5PK4Lv3AVySbSZC">Minutes</a></span><span class="c1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1-xMvUHAjqhQdegNqupxlqsLbfPHWq5MJ0iySg9Z1KBs/edit%23heading%3Dh.ym9i2k8eaxr5&amp;sa=D&amp;ust=1607595378182000&amp;usg=AOvVaw1La1Lt8pYYnp-Lp4PcRoxd">2</a></span></p><p class="c23"><span class="c3"></span></p></td></tr></tbody></table><p class="c9 c30"><span class="c3"></span></p><h1 class="c42" id="h.wlg3h8rzf61l"><span class="c1 c34 c45">Logistics</span></h1><h2 class="c16" id="h.dblx6emzzv04"><span class="c10">When</span></h2><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.w3.org/wiki/TPAC/2020/GroupMeetings%23:~:text%3DWeb%2520Performance%2520WG&amp;sa=D&amp;ust=1607595378183000&amp;usg=AOvVaw3zuEagb78q7UhHYqB44hSm">October 19-22 2020</a></span><span>&nbsp;- 9am-12pm PST</span></p><h2 class="c16" id="h.oxpoxe8f63ye"><span class="c10">Registering</span></h2><ul class="c7 lst-kix_krqcct51ae5g-0 start"><li class="c2"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.w3.org/2020/10/TPAC/registration.html&amp;sa=D&amp;ust=1607595378184000&amp;usg=AOvVaw0grWrmJp4F5GKL0nf3Pdkf">Register!</a></span></li><li class="c2"><span class="c3">Free for WG Members and Invited Experts</span></li><li class="c2"><span>If you&rsquo;re not one and want to join, ping the chairs to discuss</span></li></ul><h2 class="c16" id="h.lixi2ea9f0ds"><span class="c10">Calling in</span></h2><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://meet.google.com/gbd-iboz-zyf&amp;sa=D&amp;ust=1607595378184000&amp;usg=AOvVaw2pB3_iRqBkUjo_l61VUeoJ">Video call link</a></span></p><h2 class="c16" id="h.x2o0mg51zqnv"><span>Attendees</span></h2><ul class="c7 lst-kix_utl6c02hn3pj-0 start"><li class="c2"><span class="c3">Yoav Weiss (Google)</span></li><li class="c2"><span class="c3">Nic Jansma (Akamai)</span></li><li class="c2"><span class="c3">Nicol&aacute;s Pe&ntilde;a Moreno (Google)</span></li><li class="c2"><span class="c3">Michal Mocny (Google)</span></li><li class="c2"><span class="c3">Cliff Crocker (SpeedCurve)</span></li><li class="c2"><span class="c3">Ian Clelland (Google)</span></li><li class="c2"><span class="c3">Benjamin De Kosnik (Mozilla)</span></li><li class="c2"><span class="c3">Sean Feng (Mozilla)</span></li><li class="c2"><span class="c3">Noam Rosenthal (Invited expert)</span></li><li class="c2"><span class="c3">Steven Bougon(Salesforce)</span></li><li class="c2"><span class="c3">Noam Helfman (Microsoft)</span></li><li class="c2"><span class="c3">Andrew Comminos (Facebook)</span></li><li class="c2"><span class="c3">Nathan Schloss (Facebook)</span></li><li class="c2"><span>Nicolas</span><span class="c3">&nbsp;Dubus (Facebook)</span></li><li class="c2"><span class="c3">Patrick Hulce (Invited expert)</span></li><li class="c2"><span class="c3">Scott Haseley (Google)</span></li><li class="c2"><span class="c3">Nicole Sullivan (Google)</span></li></ul><ul class="c7 lst-kix_g7uvmsfgwgy7-0 start"><li class="c2"><span class="c3">Matt Falkenhagen (observer) (Google)</span></li><li class="c2"><span class="c3">Andrew Galloni (Cloudflare)</span></li><li class="c2"><span class="c3">Ulan Degenbaev (Google)</span></li><li class="c2"><span class="c3">Kinuko Yasuda (Google)</span></li><li class="c2"><span class="c3">Patrick Meenan (Invited expert)</span></li><li class="c2"><span class="c3">Carine Bournez (W3C)</span></li><li class="c2"><span class="c3">Subrata Ashe (Salesforce)</span></li><li class="c2"><span class="c3">Alex Christensen (Apple)</span></li><li class="c2"><span class="c3">Thomas McCabe (observer) (Squarespace)</span></li><li class="c2"><span class="c3">Nolan Lawson (Salesforce)</span></li><li class="c2"><span class="c3">Dinko Bajric (Salesforce)</span></li><li class="c2"><span class="c3">Noah Lemen (Facebook)</span></li><li class="c2"><span class="c3">Tim Dresser (Google)</span></li><li class="c2"><span class="c3">Gilles Dubuc (Wikimedia Foundation)</span></li><li class="c2"><span class="c3">Jeremy Roman (observer) (Google)</span></li><li class="c2"><span class="c3">Ian Vollick (observer) (Google)</span></li><li class="c2"><span class="c3">Utkarsh Goel (Akamai)</span></li><li class="c2"><span class="c3">Ziran sun (Igalia)</span></li><li class="c2"><span class="c3">Domenic Denicola (Google)</span></li><li class="c2"><span class="c3">Boris Schapira (invited expert, Dareboost)</span></li><li class="c2"><span class="c3">Arno Renevier (Facebook)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></li><li class="c2"><span class="c3">Alex Russell (Google, observer)</span></li><li class="c2"><span class="c3">Ryosuke Niwa (Apple)</span></li><li class="c2"><span class="c3">Camille Lamy (Google)</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h1 class="c42" id="h.tx59951gswac"><span class="c1 c34">Agenda</span></h1><p class="c9"><span>Times in PT</span></p><h2 class="c16" id="h.k0zzrh9ez9fv"><span class="c10">Monday - October 19</span></h2><p class="c9 c30"><span class="c29 c51"></span></p><a id="t.fc01130d058405add504a6c3b66482ad5d4a8aad"></a><a id="t.1"></a><table class="c43"><tbody><tr class="c14"><td class="c22" colspan="1" rowspan="1"><p class="c19"><span class="c0">Timeslot</span></p></td><td class="c20" colspan="1" rowspan="1"><p class="c31"><span class="c3">Subject</span></p></td><td class="c21 c40" colspan="1" rowspan="1"><p class="c31"><span class="c3">POC</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">9:00-9:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c31"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1-CdxwEdx9POSuNU5mcB91xXhEsenMxxZhQQLv6BDsd0/edit?ts%3D5f89fc6d%23slide%3Did.p&amp;sa=D&amp;ust=1607595378192000&amp;usg=AOvVaw2QZ1zo9DTk4xKVaVACE5XT">Intros, code of conduct, agenda review, meeting goals</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c31"><span class="c3">Yoav, Nic</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c1 c28">0</span><a id="kix.i3g915yi3nyv"></a><span class="c0">9:30-10:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1VwGIzypntWNosCTXWMsUI6ifw4sEKSRQgnwx3P_wqVg/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378194000&amp;usg=AOvVaw1HdAzXHatZbStxfNUjEryc">Frame Timing / smoothness reporting</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Michal</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:00-10:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1HjkBvWxy5C3ccIVWqIE7K8Qw4XECGKIX139DYWIzqog/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378195000&amp;usg=AOvVaw2bqACED7Yyt1HzBPEkJQGI">SpeedCurve hot topics</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Cliff</span></p></td></tr><tr class="c14"><td class="c18" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:30~10:45</span></p></td><td class="c26 c33" colspan="1" rowspan="1"><p class="c9"><span class="c3">Break</span></p></td><td class="c21 c33" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><a id="kix.v5qsezi067o5"></a><p class="c19"><span class="c0">10:45-11:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1KqfH0j-OMY6kOsAyh4impB9q4OwSfX--waenzF8iFX4/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378197000&amp;usg=AOvVaw26BXFzJ_L8tJb6vyY6ixKV">Scheduling APIs</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Scott</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">11:30-12:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1nxNFwsGqYy7WmIZ3uv_0HsSIQMSXQA9_PqlOD3V74Us/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378200000&amp;usg=AOvVaw0sNz3Dv-Y_BUaTfA0x0Rwx">Interactions and Event Timing</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Nicol&aacute;s</span></p></td></tr></tbody></table><p class="c9"><span class="c1">Recording:</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/0ty8IEEsRwE&amp;sa=D&amp;ust=1607595378201000&amp;usg=AOvVaw39lL3AFobzIiZSGClXuT4h">part 1</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/LLNewXxHJfs&amp;sa=D&amp;ust=1607595378201000&amp;usg=AOvVaw2Qh2QuRvNlkG1CGaBBlQRn">part 2</a></span></p><h2 class="c16" id="h.iekmeysj2vof"><span class="c10">Tuesday - October 20</span></h2><p class="c9 c30"><span class="c51 c29"></span></p><a id="t.ad4c64081641903ae2f2c035fc4aea18740ff96c"></a><a id="t.2"></a><table class="c43"><tbody><tr class="c14"><td class="c22" colspan="1" rowspan="1"><p class="c19"><span class="c0">Timeslot</span></p></td><td class="c20" colspan="1" rowspan="1"><p class="c31"><span class="c3">Subject</span></p></td><td class="c21 c40" colspan="1" rowspan="1"><p class="c31"><span class="c3">POC</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">9:00-10:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c31"><span class="c1">Prerendering</span><span class="c1">&nbsp;[</span><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1IuE9ZX0dCHj7z-alCDQ4iURFxeHp5HqnRyyogvM11BY/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378204000&amp;usg=AOvVaw2p3duSveX9TpfIhPquC_Wa">Page Visibility</a></span><span class="c1">] </span><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1N_VqjaD5EqnMd9doTEsa8YFTn5ben68oVPk9Pqfxgr0/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378204000&amp;usg=AOvVaw06iDUOMMhJpH2JSZP70lxM">[pre* with author support]</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c31"><span class="c3">David, Jeremy</span></p></td></tr><tr class="c14"><td class="c18" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:00~10:05</span></p></td><td class="c26 c33" colspan="1" rowspan="1"><p class="c9"><span class="c3">Break</span></p></td><td class="c21 c33" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:00-10:55</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12qJ5RwS32TJ6OVZfs64X34dRzvwhq9iK2hwSP-Z6AXE/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378206000&amp;usg=AOvVaw1YcCFHClMGIrhL86HDyiwY">SPA reporting</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Michal</span></p></td></tr><tr class="c14"><td class="c18" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:55~11:00</span></p></td><td class="c26 c33" colspan="1" rowspan="1"><p class="c9"><span class="c3">Break</span></p></td><td class="c21 c33" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><a id="kix.qmzrpt640nhb"></a><p class="c19"><span class="c0">11:00-11:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1RuQkoCmWPemOvpc89rZmVv11saPy4HVZrF5BNxtzf6w/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378208000&amp;usg=AOvVaw2moY8jlb2X-Z3Nr9_kkG3n">BFCache and performance entries</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Yoav</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">11:30-12:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/18DfHjVoL88DXw0cseFEkCIpiIUA0E_rSkEsRjY9rCPw/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378209000&amp;usg=AOvVaw1-tRl_LPsijgkH8cLCLwcg">isInputPending update</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Andrew</span></p></td></tr></tbody></table><p class="c9"><span class="c1">Recording:</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/sVUQ3HIUAKs&amp;sa=D&amp;ust=1607595378210000&amp;usg=AOvVaw3u33ZcSq5eInF7it0bR8KQ">part 1</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/9Nfe07cIw1E&amp;sa=D&amp;ust=1607595378210000&amp;usg=AOvVaw0SLchT5q4FummPTu0hoTvw">part 2</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/ie0zI18aUq8&amp;sa=D&amp;ust=1607595378210000&amp;usg=AOvVaw321LvLE2ugDV9lf_df2Ali">part 3</a></span></p><h2 class="c16" id="h.pgax8xqr4pe0"><span class="c10">Wednesday - October 21</span></h2><p class="c30 c49"><span class="c51 c29"></span></p><a id="t.7e8c16a714c15b70b9b9975e6d80a53b8a4f8887"></a><a id="t.3"></a><table class="c43"><tbody><tr class="c14"><td class="c22" colspan="1" rowspan="1"><p class="c19"><span class="c0">Timeslot</span></p></td><td class="c20" colspan="1" rowspan="1"><p class="c31"><span class="c3">Subject</span></p></td><td class="c21 c40" colspan="1" rowspan="1"><p class="c31"><span class="c3">POC</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">9:00-9:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c31"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://1drv.ms/p/s!Ajo0wos-4RKZjgw6pm1AldZ2V0iU?e%3DwaMbl1&amp;sa=D&amp;ust=1607595378212000&amp;usg=AOvVaw375ONTfgRfvKyMylvFeIRJ">Network Diagnostics API Proposal</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">NoamH</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c1 c28">0</span><a id="kix.ytkdyg4daua6"></a><span class="c0">9:30-10:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Ob63bm5iidx8-MvrIzdNLYcjLRvS4lvPAIYASURLSns/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378214000&amp;usg=AOvVaw205lxoZjqEcaC0F71ZZngf">performance.measureMemory API update</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Ulan</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:00-10:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c31"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1l8LH7OSjnzUnBcIkBzUhQpV49RmeTNszLsiqrlWAmhs/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378215000&amp;usg=AOvVaw0Xa82-JTfHvb73WN5sbLQP">Rechartering, Call for Editors</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Yoav, Nic</span></p></td></tr><tr class="c32"><td class="c18" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:30~10:45</span></p></td><td class="c26 c33" colspan="1" rowspan="1"><p class="c9"><span class="c3">Break</span></p></td><td class="c21 c33" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><a id="kix.w4xrlzifa2oa"></a><p class="c19"><span class="c0">10:45-11:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1sslnZi2MYyKlNb6LoS_vTlcvshkUR0IUekacq4mZMhs/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378217000&amp;usg=AOvVaw29-IuyPJO4QgrUp-jPTNnk">Long Tasks attribution</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">PatrickH</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">11:30-12:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1WcSza4A74y5kiuF1xNUCTKjcgTaoQBHl01FGPCGSxVo/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378218000&amp;usg=AOvVaw0bLP570JESe4Si3sKvbdWh">JS self-profiling update</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span>Andrew</span></p></td></tr></tbody></table><p class="c9"><span class="c1">Recording:</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/aID3BvpU_pE&amp;sa=D&amp;ust=1607595378218000&amp;usg=AOvVaw2xgb0jBeFveaeREUf50SdG">part 1</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/DJUlZVcSu7M&amp;sa=D&amp;ust=1607595378219000&amp;usg=AOvVaw0auD4jIJux0NU6GyNkQLdA">part 2</a></span></p><h2 class="c16" id="h.t11egqakzor0"><span class="c10">Thursday - October 22</span></h2><p class="c9 c30"><span class="c51 c29"></span></p><a id="t.8cbbbb29205f29b5e9d34b530452b1a6778c840c"></a><a id="t.4"></a><table class="c43"><tbody><tr class="c14"><td class="c22" colspan="1" rowspan="1"><p class="c19"><span class="c0">Timeslot</span></p></td><td class="c20" colspan="1" rowspan="1"><p class="c31"><span class="c3">Subject</span></p></td><td class="c21 c40" colspan="1" rowspan="1"><p class="c31"><span class="c3">POC</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">9:00-10:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1J98XeN6gwETrbO0soqQeg2kpxqoDkVRy7q3SzxrJLhM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378221000&amp;usg=AOvVaw2gysCxSUhVhLomkL8k3OcG">TAO and CORS/CORP opt-ins</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c31"><span class="c3">Yoav</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:00-10:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1MemLql-PMYyCnNKnicU9SPLwP55dhIwfe5UVFwEH5GM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378222000&amp;usg=AOvVaw1SPRGqTNUdg7-nCCSU1Vti">Reporting API updates</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span>Ian</span></p></td></tr><tr class="c14"><td class="c18" colspan="1" rowspan="1"><p class="c19"><span class="c0">10:30~10:45</span></p></td><td class="c26 c33" colspan="1" rowspan="1"><p class="c9"><span class="c3">Break</span></p></td><td class="c21 c33" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><a id="kix.i1227bq0yfii"></a><p class="c19"><span class="c0">10:45-11:30</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Wu2hK3SKKE9mMgFULLZV7u17XGe862-ZXPBvzayUZ_s/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378224000&amp;usg=AOvVaw1WegvRDWCUA9T7MOzZ73s6">Reporting API and performance metrics</a></span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9"><span class="c3">Yoav</span></p></td></tr><tr class="c14"><td class="c12" colspan="1" rowspan="1"><p class="c19"><span class="c0">11:30-12:00</span></p></td><td class="c26" colspan="1" rowspan="1"><p class="c9"><span class="c3">Overflow time</span></p></td><td class="c21" colspan="1" rowspan="1"><p class="c9 c30"><span class="c3"></span></p></td></tr></tbody></table><p class="c9"><span class="c1">Recording:</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/FUw_-WIATl0&amp;sa=D&amp;ust=1607595378225000&amp;usg=AOvVaw1i5rbpXwGjt6afHogckDwe">part 1</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/XB2nx_1Mj-4&amp;sa=D&amp;ust=1607595378225000&amp;usg=AOvVaw0UG1vhzz_ZM7JxEY0PvIG5">part 2</a></span></p><p class="c9 c30"><span class="c3"></span></p><h1 class="c42" id="h.84y0p6sgb67w"><span class="c39">Secondary Scribes</span></h1><ul class="c7 lst-kix_xp6pikmusxhf-0 start"><li class="c2"><span class="c3">Michal Mocny</span></li></ul><h1 class="c42" id="h.bdb4ylqc5s4g"><span class="c39">Session summary</span></h1><h3 class="c8" id="h.vh38dpszdymi"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1-CdxwEdx9POSuNU5mcB91xXhEsenMxxZhQQLv6BDsd0/edit?ts%3D5f89fc6d%23slide%3Did.g62c75a78d3_0_26&amp;sa=D&amp;ust=1607595378226000&amp;usg=AOvVaw1xlve0T3QCtxrdAtinbnP8">Intros, code of conduct, agenda review, meeting goals</a></span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3D0ty8IEEsRwE&amp;sa=D&amp;ust=1607595378227000&amp;usg=AOvVaw19PrJMja7yUzy5C8NZTOY-">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.h55bg4fciquh">minutes</a></span></p><h3 class="c5" id="h.uftowzrsxsdw"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1VwGIzypntWNosCTXWMsUI6ifw4sEKSRQgnwx3P_wqVg/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378227000&amp;usg=AOvVaw1AH7eB-xlU6GZ4foAIF4C2">Smoothness Reporting for Animations and Scrolling - Michal Mocny</a></span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/0ty8IEEsRwE?t%3D1382&amp;sa=D&amp;ust=1607595378227000&amp;usg=AOvVaw0i7e1ecs-3cheVTlJpvvL_">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.vnazrffddgur">minutes</a></span></p><ul class="c7 lst-kix_m106kfmnqwmr-0 start"><li class="c2"><span class="c3">In this session we outlined the goals for a potential future Smoothness / Frame Timing API for Animations (including scrolling) on the web.</span></li><li class="c2"><span class="c3">We introduced the idea of focusing on &ldquo;Missed opportunities to show expected animation updates&rdquo; (aka &ldquo;dropped frames&rdquo;) which is a more user focused measure of impact, vs just focusing on overall FPS broadly. &nbsp;We also discussed briefly what exactly would constitute an animation, &ldquo;dropped frame&rdquo;, and how smoothness relates to responsiveness.</span></li><li class="c2"><span class="c3">We also outlined several different options for surfacing the data via API (i.e.: per animation, per frame, or as a single page-level summary)</span></li><li class="c2"><span class="c3">Some topics discussed:</span></li></ul><ul class="c7 lst-kix_m106kfmnqwmr-1 start"><li class="c9 c15"><span class="c3">&ldquo;variable refresh rate&rdquo; monitors, where the decision to increase screen refresh rate could be driven by the performance of animations on the page in the first place. &nbsp;How should we balance optimizing for &ldquo;expected frames&rdquo;?</span></li><li class="c9 c15"><span class="c3">Should we have smoothness targets? &nbsp;Perhaps some applications want to reach the maximum supported device refresh rate, while others this is less critical.</span></li><li class="c9 c15"><span class="c3">Learning from the video gaming industry.</span></li><li class="c9 c15"><span class="c3">Existing metrics RUM providers track: #rAF&rsquo;s over time (however, not super useful right now)</span></li></ul><ul class="c7 lst-kix_m106kfmnqwmr-0"><li class="c2"><span class="c3">Next steps:</span></li></ul><ul class="c7 lst-kix_m106kfmnqwmr-1 start"><li class="c9 c15"><span class="c3">Address questions raised (especially around variable refresh rates)</span></li><li class="c9 c15"><span class="c3">Move proposal to github for more feedback, and open a WICG issue</span></li></ul><h3 class="c5" id="h.uislu34zy25l"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1HjkBvWxy5C3ccIVWqIE7K8Qw4XECGKIX139DYWIzqog/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378229000&amp;usg=AOvVaw2LqcLWOGodWupcUs7TeN84">SpeedCurve hot topics</a></span><span>&nbsp;- Cliff Crocker</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/0ty8IEEsRwE?t%3D3796&amp;sa=D&amp;ust=1607595378229000&amp;usg=AOvVaw3oLhXCQfDuH0vnr1kAReb1">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.574gath3vsey">minutes</a></span></p><ul class="c7 lst-kix_e2ezhny2l7lp-0 start"><li class="c2"><span class="c3">In this session we discussed the challenges and opportunities for Core Web Vitals, including how we can work to normalize metrics across synthetic and RUM that are skewed due to the measurement of the page lifecycle. </span></li><li class="c2"><span class="c3">We also discussed issues with reporting the performance of third-parties, specifically ads and the urgency of several proposed issues related to measurement of same origin and cross-origin frames. </span></li><li class="c2"><span class="c3">The topic of server timing was also briefly raised, specifically how we should be encouraging others to adopt this (CDNs as well as developers) in an effort to provide a better understanding of what is impacting TTFB.</span></li><li class="c2"><span class="c3">Next steps:</span></li></ul><ul class="c7 lst-kix_e2ezhny2l7lp-1 start"><li class="c9 c15"><span class="c3">Look at how we can effectively leverage Reporting API to more accurately measure load-limited metrics.</span></li><li class="c9 c15"><span class="c3">Work with browser vendors and others to potentially adjust CWV thresholds such as FID to be more meaningful</span></li><li class="c9 c15"><span class="c3">Push for the prioritization of several open issues related to measuring resources w/in iframes</span></li><li class="c9 c15"><span class="c3">More discussion needed around third-party script scheduling/reporting API</span></li></ul><h3 class="c5" id="h.7a1cp6gubves"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1KqfH0j-OMY6kOsAyh4impB9q4OwSfX--waenzF8iFX4/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378231000&amp;usg=AOvVaw1f2e9XhcScTHI9-LvD7JHO">Main Thread Scheduling APIs</a></span><span>&nbsp;- Scott Haseley</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3DLLNewXxHJfs&amp;sa=D&amp;ust=1607595378231000&amp;usg=AOvVaw2YxUz0iFuIy6MpyGv_a4Ng">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.z0rsadstvhrv">minutes</a></span></p><ul class="c7 lst-kix_lr9db4ky8niv-0 start"><li class="c2"><span class="c3">We presented the various scheduling problems and APIs our team is focused on</span></li></ul><ul class="c7 lst-kix_lr9db4ky8niv-1 start"><li class="c9 c15"><span>scheduler.postTask: Queue tasks with browser scheduler, with ability to cancel and reprioritize groups of tasks (</span><span class="c29">in OT through mid-January 2021</span><span class="c3">).</span></li><li class="c9 c15"><span>scheduler.currentTaskSignal: provide a way to provide the current task context (priority, etc.) (</span><span class="c29">also in OT through mid-January 2021)</span><span class="c3">.</span></li><li class="c9 c15"><span class="c1">Yield:</span><span class="c3">&nbsp;Provide an ergonomic and efficient method of breaking up long tasks (revised, narrowly-scoped proposal in progress)</span></li><li class="c9 c15"><span>3P Script Scheduling: provide developers with some control over scheduling 3P execution on main thread (</span><span class="c29">currently exploring data and API shapes</span><span class="c3">).</span></li></ul><ul class="c7 lst-kix_lr9db4ky8niv-0"><li class="c2"><span class="c3">We discussed several other problems/APIs on our radar</span></li></ul><ul class="c7 lst-kix_lr9db4ky8niv-1 start"><li class="c9 c15"><span class="c3">Priorities on other async work, task ordering guarantees, more context propagation, interaction of postTask and rendering, scheduling microtasks, after-task callbacks, etc.</span></li></ul><ul class="c7 lst-kix_lr9db4ky8niv-0"><li class="c2"><span class="c3">Some discussion on 3P scheduling and the idea of creating &ldquo;scheduling domains&rdquo; to isolate parts of the page</span></li><li class="c2"><span class="c3">AIs/Next steps</span></li></ul><ul class="c7 lst-kix_lr9db4ky8niv-1 start"><li class="c9 c15"><span>Share more concrete thoughts about yield and 3P scheduling with group as proposals take shape</span></li></ul><h3 class="c5" id="h.9rvruchl8pjv"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1nxNFwsGqYy7WmIZ3uv_0HsSIQMSXQA9_PqlOD3V74Us/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378233000&amp;usg=AOvVaw39E470qCGX833hstiNLRsu">Interactions and Event Timing - Nicol&aacute;s Pe&ntilde;a Moreno</a></span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/LLNewXxHJfs?t%3D2626&amp;sa=D&amp;ust=1607595378234000&amp;usg=AOvVaw1_O62KaU7ltFRFm9sNvGJF">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.2wxzuvisl3kx">minutes</a></span></p><ul class="c7 lst-kix_1zsvssxdqfab-0 start"><li class="c2"><span class="c3">We talked about the main problems with First Input Delay (FID):</span></li></ul><ul class="c7 lst-kix_1zsvssxdqfab-1 start"><li class="c9 c15"><span class="c3">It does not measure end-to-end-latency </span></li><li class="c9 c15"><span class="c3">It only considers the first user interaction. </span></li></ul><ul class="c7 lst-kix_1zsvssxdqfab-0"><li class="c2"><span class="c3">For the former problem, we need to consider asynchronous work, which is related to Patrick Hulce&#39;s talk on longtasks. </span></li><li class="c2"><span class="c3">For the second problem, we proposed exposing an interactionID which would enable knowing which events correspond to the same user interaction and would allow correctly aggregating the entries received to compute a per-page metric. </span></li><li class="c2"><span class="c3">We discussed the various open questions, such as how to handle pointerdowns (not all end up in clicks) and more continuous events like drags.</span></li></ul><h3 class="c8" id="h.qwjrhr3z34m9"><span>Prerendering</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1N_VqjaD5EqnMd9doTEsa8YFTn5ben68oVPk9Pqfxgr0/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378235000&amp;usg=AOvVaw3KAr90oRfDA7UuDQ4WBcry">[pre* with author support]</a></span><span>&nbsp;- Jeremy Roman</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3DsVUQ3HIUAKs&amp;sa=D&amp;ust=1607595378235000&amp;usg=AOvVaw1G1APV3qxxtNM02tq3fVGY">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.nh9xf4k3tm9p">minutes</a></span></p><ul class="c7 lst-kix_dkijbe2i5rcp-0 start"><li class="c2"><span class="c3">Discussed how current browser privacy models interact with prerendering, and what measures are needed to be consistent with anti-tracking measures.</span></li><li class="c2"><span class="c3">Discussed prerendering an uncredentialed version of the page and have developers &ldquo;upgrade&rdquo; it when the user navigates.</span></li><li class="c2"><span class="c3">Some attendees had questions on the necessity of an &ldquo;upgrade path&rdquo; compared to loading credentialed pages in their own partition.</span></li><li class="c2"><span class="c3">Some attendees expressed concerns about whether prerendering is likely to succeed given mixed results in previous attempts.</span></li><li class="c2"><span class="c3">We briefly discussed the implications of prerendering on performance measurement APIs and Core Web Vitals, saying that we likely want to report both the prerendered load and the user&rsquo;s experience navigating to a prerendered page.</span></li><li class="c2"><span>One attendee expressed concern that prerendering may be vulnerable to timing attacks of some kind, which could be investigated later.</span></li></ul><h3 class="c5" id="h.qsaihnv1310x"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1IuE9ZX0dCHj7z-alCDQ4iURFxeHp5HqnRyyogvM11BY/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378236000&amp;usg=AOvVaw3Wbku30mF-FTds7HPICqTw">Prerender PageVisibility</a></span><span>&nbsp;- David Bokan</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/sVUQ3HIUAKs?t%3D1826&amp;sa=D&amp;ust=1607595378237000&amp;usg=AOvVaw1OXHAkVfMjQA23r8d8phTj">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.mt1aoksixjtv">minutes</a></span></p><ul class="c7 lst-kix_85s0agn6ebst-0 start"><li class="c2"><span class="c3">Discussed options for how page state should be reported in prerendering/portals modes. Should we bring back visibilityState == &lsquo;prerender&rsquo;?</span></li><li class="c2"><span>Related issues were brought up around tab/app switchers, where the page is visibilityState == &lsquo;hidden&rsquo; but content is still shown. Related to </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/59&amp;sa=D&amp;ust=1607595378237000&amp;usg=AOvVaw2C3792pKCYj_6yGvuxQNju">#59</a></span></li><li class="c2"><span>Decided more investigation was needed, Domenic suggested enumerating all the use cases and states and trying to find some reasonable set of exposable states. David Bokan looking into that.</span></li></ul><h3 class="c5" id="h.3pxuamr9quk4"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12qJ5RwS32TJ6OVZfs64X34dRzvwhq9iK2hwSP-Z6AXE/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378238000&amp;usg=AOvVaw32W4jaPLE9EBCeFGnr4wYJ">SPA reporting</a></span><span>&nbsp;- Michal Mocny</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/9Nfe07cIw1E?t%3D48&amp;sa=D&amp;ust=1607595378238000&amp;usg=AOvVaw2cI-aMAmnm3MaTzDhPwoj2">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.vhoche6vbj9x">minutes</a></span></p><ul class="c7 lst-kix_go2xi6t0lvgg-0 start"><li class="c2"><span class="c3">In this session we review SPA navigation and problems they provide with RUM metrics gathering, as well as synthetic testing.</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-1 start"><li class="c9 c15"><span class="c3">Review, then discuss what it would mean to identify a soft navigation and how we would ideally change what we measure.</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-0"><li class="c2"><span class="c1">Discussion:</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-1 start"><li class="c9 c15"><span class="c3">Patterns typical with performance measurement when transitioning from MPA to SPA today, as well as issues with Attribution.</span></li><li class="c9 c15"><span class="c3">Issues with blending performance metrics between initial Page Load and soft navigation.</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-2 start"><li class="c9 c13"><span class="c3">Is it important to measure &ldquo;MPA vs SPA&rdquo; or &ldquo;first in session&rdquo; vs not (&ldquo;landing page vs not&rdquo;)?</span></li><li class="c9 c13"><span class="c3">Today, the &ldquo;default&rdquo; for MPA is a blended report across all nav types. &nbsp;The &ldquo;default&rdquo; for SPA is a segmented report with focus on landing pages (by the nature of perf reports).</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-1"><li class="c9 c15"><span class="c3">Effects of Caching (on both page load and soft nav)</span></li><li class="c9 c15"><span class="c1">Request:</span><span class="c3">&nbsp;support resetting all metrics when timeline is marked by developer.</span></li><li class="c9 c15"><span class="c3">How to reset Paint timing? &nbsp;Suggestion: browsers should do the naive thing, and developers can use Element Timing if they need something smarter.</span></li><li class="c9 c15"><span class="c3">Security concerns about measuring arbitrary paints.</span></li><li class="c9 c15"><span class="c3">History API URL update is a single moment in time, but soft navigations are a span of time. &nbsp;Sometimes most work comes before the URL update, sometimes URL is the first thing, and often the URL is updated arbitrarily in the middle.</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-0"><li class="c2"><span class="c3">Next Steps:</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-1 start"><li class="c9 c15"><span class="c3">Need more blog posts :)</span></li><li class="c9 c15"><span>Create a public repo, with focus on listing out </span><span class="c29">concrete</span><span class="c3">&nbsp;use cases we aim to solve (with a focus on real existing apps and problems if possible).</span></li></ul><ul class="c7 lst-kix_go2xi6t0lvgg-2 start"><li class="c9 c13"><span class="c3">Aim to ask large web property owners to submit use cases.</span></li></ul><h3 class="c5" id="h.qh504qmhx08s"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1RuQkoCmWPemOvpc89rZmVv11saPy4HVZrF5BNxtzf6w/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378240000&amp;usg=AOvVaw1X--1Lcj6qUw3PHVeUZEaH">BFCache Reporting</a></span><span class="c24">&nbsp;- Yoav Weiss</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3Die0zI18aUq8&amp;sa=D&amp;ust=1607595378241000&amp;usg=AOvVaw2NyiYOQ4cnXUv0GbxZn4Cg">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.wp52ifyio7ww">minutes</a></span></p><ul class="c7 lst-kix_44aolqkom00p-0 start"><li class="c2"><span class="c3">We discussed the various options of exposing BFCache navigations, and the backwards compatibility implications of firing new NavigationTiming entries</span></li><li class="c2"><span class="c3">Decided that the option of firing a new typed NavigationTiming entry is the way to go here, as well as firing the relevant First* entries that go along with it.</span></li></ul><h3 class="c5" id="h.8hh2ot9q68yu"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/18DfHjVoL88DXw0cseFEkCIpiIUA0E_rSkEsRjY9rCPw/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378242000&amp;usg=AOvVaw2g-IN6xz0L4UqvmNL-HH3K">isInputPending update</a></span><span>&nbsp;- Andrew Comminos</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/ie0zI18aUq8?t%3D1253&amp;sa=D&amp;ust=1607595378242000&amp;usg=AOvVaw06NHwQkbO3hbSaW_p2g0Ex">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.dnfpgep5a3iw">minutes</a></span></p><p class="c9"><span class="c3">- Status update</span></p><p class="c9"><span class="c3">&nbsp; - Shipping in Chrome 87</span></p><p class="c9"><span class="c3">- Discussed interactions with Long Tasks API</span></p><p class="c9"><span class="c3">&nbsp; - Decided to report isInputPending usage inside of long tasks as a boolean or &quot;input starved&quot; signal, rather than omit entirely</span></p><p class="c9"><span class="c3">- Discussed potential interop with yielding APIs</span></p><p class="c9"><span class="c3">&nbsp; - Deemed unnecessary to yield only to input</span></p><p class="c9"><span class="c3">&nbsp; - Current behaviour with setTimeout works for most UAs (particularly those who dispatch events FIFO)</span></p><p class="c9 c30"><span class="c3"></span></p><h3 class="c8" id="h.c56xrpf0eusl"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://1drv.ms/p/s!Ajo0wos-4RKZjgw6pm1AldZ2V0iU?e%3DwaMbl1&amp;sa=D&amp;ust=1607595378243000&amp;usg=AOvVaw1MCmR_HITDgjr4JG-NmGbI">Network Diagnostics API Proposal</a></span><span>&nbsp;- Noam Helfman</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3DaID3BvpU_pE%26feature%3Dyoutu.be&amp;sa=D&amp;ust=1607595378244000&amp;usg=AOvVaw1yG0zn_y1TxbiJ-BezXWDd">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.8gfnc7p4nih">minutes</a></span></p><ul class="c7 lst-kix_44bk24uu1uv5-0 start"><li class="c38 c46"><span class="c3">Discussed different use cases and tools for network information diagnostics.</span></li><li class="c38 c46"><span class="c3">Proposal to extend network information API with custom threshold a custom logic handling network condition changes has been discussed.</span></li><li class="c38 c46"><span class="c3">Proposal for a new API to ping local gateway has been presented &ndash; there was some pushback related to privacy and insufficient clarity and justification for the use case.</span></li></ul><p class="c38"><span class="c3">&nbsp;</span></p><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.afz3u7yf6pki"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Ob63bm5iidx8-MvrIzdNLYcjLRvS4lvPAIYASURLSns/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378245000&amp;usg=AOvVaw3nu8yfgZtbU0gvryFX-2I2">performance.measureMemory API update</a></span><span>&nbsp;- Ulan Degenbaev</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/aID3BvpU_pE?t%3D2079&amp;sa=D&amp;ust=1607595378245000&amp;usg=AOvVaw1WR68USiKO55LxN84UD8Bg">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.61181ucixzu">minutes</a></span></p><ul class="c7 lst-kix_fysp1ztzgb8r-0 start"><li class="c2"><span class="c3">Recent changes to the API were presented:</span></li></ul><ul class="c7 lst-kix_fysp1ztzgb8r-1 start"><li class="c9 c15"><span class="c3">The API is now gated behind self.crossOriginIsolated</span></li><li class="c9 c15"><span class="c3">The API provides information to identify iframes in the result</span></li><li class="c9 c15"><span class="c3">The format of the result is generalized to allow other memory types beside JS.</span></li></ul><ul class="c7 lst-kix_fysp1ztzgb8r-0"><li class="c2"><span class="c3">We discussed whether &quot;bytes&quot; in the result mean physical bytes or virtual bytes.</span></li><li class="c2"><span>We discussed the scope of the API and whether it should report the whole browsing context group or not. Concerns were raised about reporting memory usage of cross-origin iframes and potentially exposing the underlying process model.</span></li></ul><h3 class="c8" id="h.5cz7c1uuzsvv"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1l8LH7OSjnzUnBcIkBzUhQpV49RmeTNszLsiqrlWAmhs/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378246000&amp;usg=AOvVaw1HM7J-Ev7joZK0AIDvEm6d">Rechartering, Call for Editors</a></span><span class="c24">&nbsp;- Yoav, Nic</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/aID3BvpU_pE?t%3D4158&amp;sa=D&amp;ust=1607595378247000&amp;usg=AOvVaw0OBrE7yK5-hvT8ogbEoLEW">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.frj07uevyuvj">minutes</a></span></p><ul class="c7 lst-kix_s4ykfd3t2gn3-0 start"><li class="c2"><span>We discussed the </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit%23heading%3Dh.giqsyxufsysg&amp;sa=D&amp;ust=1607595378247000&amp;usg=AOvVaw3VC4m6uVW-UWZddW_adgPo">charter draft</a></span><span class="c3">&nbsp;and various decisions that we needed to make</span></li><li class="c2"><span class="c3">We decided not to try and publish &ldquo;almost done&rdquo; specs to REC before the rechartering, or at least not block on that</span></li><li class="c2"><span class="c3">There was general agreement on moving most specs to the CR-based living standard model</span></li><li class="c2"><span class="c3">For specs transitioning out of the Group, we decided to move them out of the deliverables.</span></li></ul><h3 class="c5" id="h.spaskalkznsf"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1sslnZi2MYyKlNb6LoS_vTlcvshkUR0IUekacq4mZMhs/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378248000&amp;usg=AOvVaw1FUQfiWExjBCXCjInAFkfu">Long Tasks attribution</a></span><span>&nbsp;- Patrick Hulce</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3DDJUlZVcSu7M%26feature%3Dyoutu.be&amp;sa=D&amp;ust=1607595378248000&amp;usg=AOvVaw1U3RlV61WoNcq6h9dMkcoK">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.ft9c84pgmoe5">minutes</a></span></p><ul class="c7 lst-kix_xglyqeugday7-0 start"><li class="c2"><span class="c3">We discussed the motivation for attribution and several previous attempts in lab tooling that did not work very well toward that goal.</span></li><li class="c2"><span class="c3">We outlined the approach that is currently working well in lab tooling and discussed its implementation cost which uses intertask initiator information.</span></li><li class="c2"><span class="c3">There was some interest in exploring this as an addition to the long tasks spec.</span></li><li class="c2"><span class="c3">There was some concern about the implementation cost that will require some further research.</span></li><li class="c2"><span class="c1">AI:</span><span>&nbsp;Patrick Hulce to file an issue for further discussion.</span></li></ul><h3 class="c5" id="h.9uskdhbxdwkg"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1WcSza4A74y5kiuF1xNUCTKjcgTaoQBHl01FGPCGSxVo/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378249000&amp;usg=AOvVaw0tciWZ7AIBzxrwQEu91Bl-">JS self-profiling update</a></span><span>&nbsp;- Andrew Comminos</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/DJUlZVcSu7M?t%3D2249&amp;sa=D&amp;ust=1607595378250000&amp;usg=AOvVaw0J_zrz3EE663FKqTukJKOV">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.kfbl5bobg2q9">minutes</a></span></p><p class="c9"><span class="c3">- Presented results from Chrome origin trial</span></p><p class="c9"><span class="c3">&nbsp; - Positive developer sentiment, useful to discover pathologically bad cases</span></p><p class="c9"><span class="c3">- Discussed activation mechanism</span></p><p class="c9"><span class="c3">&nbsp; - AI: Add support for disabled-by-default features to Permission Policy</span></p><p class="c9"><span class="c3">- Talked about potential candidates for renaming</span></p><p class="c9"><span class="c3">&nbsp; - Popular candidates included JavaScript Sampling API, Performance Profiler</span></p><p class="c9"><span class="c3">&nbsp; - AI: File GitHub issue, request feedback from TAG</span></p><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.u6tiv4d63i38"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1J98XeN6gwETrbO0soqQeg2kpxqoDkVRy7q3SzxrJLhM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378251000&amp;usg=AOvVaw0fMrAq63hy6MLg2Tmh4Rh2">TAO and CORS/CORP opt-ins</a></span><span class="c24">&nbsp;- Yoav Weiss</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://www.youtube.com/watch?v%3DFUw_-WIATl0%26feature%3Dyoutu.be&amp;sa=D&amp;ust=1607595378252000&amp;usg=AOvVaw3yfYSlItDAaRlXsEmRYsVx">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.cc3elzozxjup">minutes</a></span></p><ul class="c7 lst-kix_wt0va7c3wljs-0 start"><li class="c2"><span class="c3">We discussed the different categories of information Timing APIs expose and how we can reason about unifying the opt-ins for them.</span></li><li class="c2"><span class="c3">We concluded that while CORS does give you access to resource-level information (timing + size), it doesn&rsquo;t currently provide origin-level or network-level information, so we shouldn&rsquo;t extend its semantics to include those.</span></li><li class="c2"><span class="c3">We discussed whether CORP should enable exposure of resource size, which devolved into a discussion of the semantics of CORP, and whether it implies that a resource can be just embedded or embedded and read.</span></li><li class="c2"><span class="c1">AI:</span><span class="c3">&nbsp;Yoav to sum up the discussion on an issue, so we can continue it there</span></li></ul><h3 class="c5" id="h.cyzxjzmp0jtr"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1MemLql-PMYyCnNKnicU9SPLwP55dhIwfe5UVFwEH5GM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378253000&amp;usg=AOvVaw0y-4t_22fmDRpVxqjOIm9E">Reporting API updates</a></span><span>&nbsp;- Ian Clelland</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/FUw_-WIATl0?t%3D3897&amp;sa=D&amp;ust=1607595378253000&amp;usg=AOvVaw3XPocsWuZpsxDPj9R254eG">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.6na6dc1pssqh">minutes</a></span></p><ul class="c7 lst-kix_6ppucfqmpony-0 start"><li class="c2"><span class="c3">Changes made over the last year to the Reporting and Network Reporting specs were presented, along with an update on their implementation and usage within Chrome.</span></li><li class="c2"><span class="c3">We discussed the need for something like Origin Policy to enable out-of-band configuration of Network Reporting, though Origin Policy has some blockers that have prevented it shipping so far.</span></li><li class="c2"><span class="c3">We discussed whether there was interest from any non-Chromium implementers to ship Reporting</span></li><li class="c2"><span class="c3">We discussed how best to resolve the remaining privacy issues on the spec, including when it is appropriate to bring these issues to the Privacy IG / CGs</span></li><li class="c2"><span>We discussed whether anything other than spec-level guidance can be done about the problem of capability URLs appearing in cross-origin reports.</span></li></ul><h3 class="c5" id="h.sotg9t2qmuek"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Wu2hK3SKKE9mMgFULLZV7u17XGe862-ZXPBvzayUZ_s/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378254000&amp;usg=AOvVaw3G_3El9nTuq0qesHEyIY8w">Reporting API and performance metrics</a></span><span class="c24">&nbsp;- Yoav Weiss</span></h3><p class="c9"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://youtu.be/XB2nx_1Mj-4&amp;sa=D&amp;ust=1607595378255000&amp;usg=AOvVaw3gVeKv-16gm46cHCvR84IW">Video</a></span><span>, </span><span class="c11"><a class="c4" href="#h.n569ki9kzyv2">minutes</a></span></p><ul class="c7 lst-kix_79jgx4uzqe5g-0 start"><li class="c2"><span class="c3">We discussed a proposal for a reporting API, where developers construct the metrics they want reported in JS, but the browser ensures the reports are sent before the document is dismissed.</span></li></ul><ul class="c7 lst-kix_79jgx4uzqe5g-1 start"><li class="c9 c15"><span class="c3">that will increase report reliability and prevent developers from having to rely on dismissal events to manually send their beacons.</span></li></ul><ul class="c7 lst-kix_79jgx4uzqe5g-0"><li class="c2"><span class="c3">We concluded that such a proposal would be useful to reduce the need for backend &ldquo;session stitching&rdquo;, even if this requirement will not go away entirely in cases where we want to report both real-time and continuous results.</span></li><li class="c2"><span>RUM providers expressed interest and said they&rsquo;d migrate to such a solution, if available</span></li></ul><h1 class="c42" id="h.7tyyh89u1vpi"><span class="c39">Minutes</span></h1><h2 class="c16" id="h.nua86znlrrtj"><span class="c10">Monday Oct 19</span></h2><h3 class="c8" id="h.h55bg4fciquh"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1-CdxwEdx9POSuNU5mcB91xXhEsenMxxZhQQLv6BDsd0/edit?ts%3D5f89fc6d%23slide%3Did.g62c75a78d3_0_26&amp;sa=D&amp;ust=1607595378256000&amp;usg=AOvVaw3mUI4Wq2Qa6PdYpwt76FPc">Intros, code of conduct, agenda review, meeting goals</a></span></h3><ul class="c7 lst-kix_u2unz1dpmlhd-0 start"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Welcome!</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;Welcome to TPAC!</span></li><li class="c2"><span class="c3">... Mission is to think about, measure performance of web. &nbsp;User agent features and APIs</span></li><li class="c2"><span class="c3">... Highlights: New co-chair, HR Time L2, PaintTiming WebKit implemented</span></li><li class="c2"><span class="c3">... F2F SPA focused interim meeting was cancelled due to COVID</span></li><li class="c2"><span class="c3">... Closed 86 issues in Github</span></li><li class="c2"><span class="c3">... Rechartering discussion on Wednesday</span></li></ul><ul class="c7 lst-kix_u2unz1dpmlhd-1 start"><li class="c9 c15"><span class="c1">Draft:</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit&amp;sa=D&amp;ust=1607595378257000&amp;usg=AOvVaw1lwUQWd0_fHyM4a0FUk7my">https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit</a></span></li><li class="c9 c15"><span class="c3">Current charter runs through 2020-12-31</span></li></ul><ul class="c7 lst-kix_u2unz1dpmlhd-0"><li class="c2"><span class="c3">... Call for Editors - also on Wednesday. Looking for new editors to take specs forward</span></li><li class="c2"><span class="c3">... Lots of incubations we may want to adopt: 13!</span></li><li class="c2"><span class="c3">... Usage is up (mostly)</span></li><li class="c2"><span class="c3">... New member organizations and invited experts</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;W3C has a code of conduct (CEPC)</span></li><li class="c2"><span class="c3">... Promote diversity and seek diverse perspectives</span></li><li class="c2"><span class="c3">... Try to avoid speakers dominating time</span></li><li class="c2"><span class="c3">... We don&#39;t operate a queue, prefer natural discussion</span></li><li class="c2"><span class="c3">... We can use chat to indicate they want to speak</span></li><li class="c2"><span class="c3">... CEPC has section on unacceptable behavior and safety vs. comfort, important to to read</span></li><li class="c2"><span class="c3">... We are recording this event and will be publishing this later</span></li><li class="c2"><span class="c3">... Agenda for today</span></li><li class="c2"><span class="c3">... (round of introductions)</span></li></ul><h3 class="c5" id="h.vnazrffddgur"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1VwGIzypntWNosCTXWMsUI6ifw4sEKSRQgnwx3P_wqVg/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378259000&amp;usg=AOvVaw11Q3zVHI1uOL95ufNjHayW">Smoothness Reporting for Animations and Scrolling - Michal Mocny</a></span></h3><ul class="c7 lst-kix_y6nkyhcgp06z-0 start"><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Why discuss smoothness?</span></li><li class="c2"><span class="c3">... Animation and Scrolling is big part of UX on the web</span></li><li class="c2"><span class="c3">... Stuttering is very visible</span></li><li class="c2"><span class="c3">... How do we measure smoothness?</span></li><li class="c2"><span class="c3">... Often in terms of FPS, especially coming from gaming</span></li><li class="c2"><span class="c3">... When it comes to the web, it has some flaws. &nbsp;A perfectly static website is perfectly smooth, doesn&#39;t generate any new frames</span></li><li class="c2"><span class="c3">... With multi-threading, what does FPS even measure</span></li><li class="c2"><span class="c3">... Why it matters: Missed opportunities to show expected animation updates, aka &quot;dropped frames&quot;</span></li><li class="c2"><span class="c3">... Animations: Scroll, pinch/zoom, rAF loops, CSS, canvas/video/etc</span></li><li class="c2"><span class="c3">... Animations are not: inserting new content, clicking button to produce UX response, form input appearances, background loading</span></li><li class="c2"><span class="c3">... Dropped frames: Anytime an animation is expected to produce an update for vsync, yet the page does not do so</span></li><li class="c2"><span class="c3">... Animations do not always expect to produce an update</span></li><li class="c2"><span class="c3">... CSS animations can have idle periods defined</span></li><li class="c2"><span class="c3">... Event handlers can delay animations based on scrolls in multiple ways (e.g. delays in handler or triggering updates afterwards)</span></li><li class="c2"><span class="c3">... How do we report on missed animations?</span></li><li class="c2"><span class="c3">... Option 1: Report all raw data points, and see which animations are able to complete for each frame ID</span></li><li class="c2"><span class="c3">... Concerns: ergonomics, performance, privacy/security</span></li><li class="c2"><span class="c3">... Option 2: Report per animation (summary) at the end</span></li><li class="c2"><span class="c3">... Simplifies attribution</span></li><li class="c2"><span class="c3">... Report #expected frames, #produced frame, duration</span></li><li class="c2"><span class="c3">... Can calculate %smooth or FPS</span></li><li class="c2"><span>... straw API:</span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 221.33px;"><img alt="" src="images/image18.png" style="width: 624.00px; height: 221.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">... Option 3: Report per frame (on timeline), similar to FrameTiming API proposal</span></li><li class="c2"><span class="c3">... Better matches to what user experiences</span></li><li class="c2"><span class="c3">... Number of updates produced / expected</span></li><li class="c2"><span class="c3">... Option 4: Single summary, &quot;final smoothness&quot;</span></li><li class="c2"><span class="c3">... Or maybe at key moments such as visibility changes</span></li><li class="c2"><span class="c3">... Mix and match the options</span></li><li class="c2"><span class="c3">... Could offer page-level summary but also give details per animation or something</span></li><li class="c2"><span class="c3">... Open questions:</span></li><li class="c2 c30"><span class="c3"></span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 281.33px;"><img alt="" src="images/image3.png" style="width: 624.00px; height: 281.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;What do you mean by expected frames in option 2?</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;For a CSS animation, for a key frame that was expected to move from the previous frame, and if the browser cannot produce it in time</span></li><li class="c2"><span class="c3">... for animations where there&#39;s no transform between keyframes, there&#39;s no expected new frame being produced</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;In some environments, they adjust frame rates based on what&#39;s animated.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;In Option 2, there is an interval (which is avg vsync interval), so if frame rate increased, the interval would change</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Assuming you can get that information, I&#39;m not sure we have that capability</span></li><li class="c2"><span class="c3">... For JS based animations, it can be more complex because we&#39;re depending on script to draw or not. &nbsp;Not clear if we missed a frame. &nbsp;Expectation of a frame is complex to me.</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;It&#39;s unclear in the case where vsync is not constant. &nbsp;In the case where it is constant, is it hard to know if there&#39;s no change?</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Hard to define this. On a device that was 120hz, and an animation that started when the page was running at 30hz, and it needs to ramp up. &nbsp;Number of frames being produced is dependent on the animation being done.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;In this case there was an opportunity to present (vsync), but it could not be</span></li><li class="c2"><span class="c1">Sadrul:</span><span class="c3">&nbsp;&quot;The next rendering opportunity&quot;. &nbsp;Have to depend on the system to give the presentation frequency. &nbsp;If a device ramps up from 30 to 60 to 120fps, for each framerate, we know up to how many frames we can present.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;On fast displays (120hz), the page may not be able to even animate that fast</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;You can switch refresh-rate and not affect the UX</span></li><li class="c2"><span class="c3">... Look at dropped frames per unit time, instead of dropped frames per expected frames</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;If everywhere else, pages are rendering at 120hz, and another page is only at 30hz, the user would notice the difference</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Does the refresh rate ramp up for developer-provided frames? &nbsp;CSS animations are defined semantically, but what about rAF loops where the developer code just tries to keep up. </span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;The system is deciding how fast to present things. &nbsp;It sees how fast you&#39;re going and then tries to goes faster. &nbsp;I don&#39;t know the exact algorithm here.</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;Seems like you have better experience with variable refresh rate cases, do you have alternate ideas on how to present UX in those cases</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;These are really hard cases</span></li><li class="c2"><span class="c3">... In the case where refresh rate isn&#39;t changing at all, there&#39;s no problem</span></li><li class="c2"><span class="c3">... I don&#39;t really have a great suggestion here</span></li><li class="c2"><span class="c1">Robert:</span><span class="c3">&nbsp;If we know the system has the opportunity to ramp up, we know any other rate is dropped frames.</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Would it make sense for API to allow developers to specify what they&#39;re interested in for smoothness criteria. e.g. in some applications, 20FPS is OK, in some it&#39;s intolerable below 50-60FPS.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;If we can say here&#39;s the theoretical max rate this device is capable of versus what it presents at</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;The worst thing to happen is there was an opportunity to present, and the animation had a useful thing to give, but for whatever reason it wasn&#39;t updated</span></li><li class="c2"><span class="c3">... There are other things to optimize for, like having the interval as low as possible. &nbsp;But you want to make sure you want to present when you have the opportunity to</span></li><li class="c2"><span class="c3">Patrick Meenan: Would be useful to look at the video game industry for guidance, e.g. report device supported and minimum framerate, percentiles</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;That kind of research seems valuable to me. &nbsp;We could also take a look at the time it takes to present a frame. &nbsp;Downside of being less representative of user experience.</span></li><li class="c2"><span class="c1">Sadrul:</span><span class="c3">&nbsp;How do other vendors measure smoothness right now</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;We do capture very simple metrics: frame rate over time, but not very valuable, due to the issues presented here. Would love more useful UX metrics. Currently just measuring rAF.</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Is the intent to grow towards media capabilities WG and have this be applicable to video?</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Haven&rsquo;t considered that</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;A good job for the video use-case would require a lot of additional data, bitrate being streamed, etc. My guess is that it&rsquo;d need first-class support</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;So different APIs</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;My intuition is that would be the way to go. This would handle video in a sane way, but won&rsquo;t give a full picture of video smoothness</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Other thoughts?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;In many ways it&rsquo;s nice to report on the &ldquo;bad&rdquo; things. Easier to present or track user pain. Even just counts of dropped frames is useful to track</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Video/media use cases are in-scope for other WGs. We can talk to them</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Next steps - expect more on this</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Any repo where this is being discussed</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Coming soon</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Let us know!</span></li></ul><h3 class="c5" id="h.574gath3vsey"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1HjkBvWxy5C3ccIVWqIE7K8Qw4XECGKIX139DYWIzqog/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378270000&amp;usg=AOvVaw0prMZTwuZEIwjYwBkdK50x">SpeedCurve hot topics</a></span><span class="c24">&nbsp;- Cliff Crocker</span></h3><ul class="c7 lst-kix_bntp2tfkmlw3-0 start"><li class="c2"><span class="c1">Ciff:</span><span class="c3">&nbsp;Working on webperf for ~18 years. Want to give some feedback and report what customers are seeing in the wild</span></li><li class="c2"><span class="c3">... Core Web Vitals, ads measurement, Server Timing</span></li><li class="c2"><span class="c3">... Seen a huge wave of interest as a result of Core Web Vitals in terms of people wanting to make their sites faster, from outside our echo chambers: SEO, marketing, CEOs, etc</span></li><li class="c2"><span class="c3">... Problems: Browser support for the metrics. Want to see adoption beyond just Google (Facebook, Adobe analytics and other marketing tools)</span></li><li class="c2"><span class="c3">... LCP RUM data: p50 1.2s, p75 2.2s, p95 5.2s</span></li><li class="c2"><span class="c3">... LCP been easy to understand and people tend to be doing well here</span></li><li class="c2"><span class="c3">... Chrome 86 fixed opacity issues, resulting in more accurate (higher) LCPs</span></li></ul><ul class="c7 lst-kix_bntp2tfkmlw3-1 start"><li class="c9 c15"><span class="c3">But getting support calls as a result, may result in erosion of confidence in the metric</span></li></ul><ul class="c7 lst-kix_bntp2tfkmlw3-0"><li class="c2"><span class="c1">Nic:</span><span>&nbsp;Chrome has a </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://meet.google.com/linkredirect?authuser%3D0%26dest%3Dhttps%253A%252F%252Fchromium.googlesource.com%252Fchromium%252Fsrc%252F%252B%252Fmaster%252Fdocs%252Fspeed%252Fmetrics_changelog%252FREADME.md&amp;sa=D&amp;ust=1607595378271000&amp;usg=AOvVaw0M8dSUBYnsGWRC1GCRGLxJ">public change log</a></span><span class="c3">, that we can point mPulse customers to better understand those changes. &nbsp;Helpful for browser vendors to share that.</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Yeah, we recently started doing something similar</span></li><li class="c2"><span class="c3">&hellip; CLS - people are doing relatively well, but depends on industry</span></li><li class="c2"><span class="c3">&hellip; Took some time to get people&rsquo;s heads around that. We got over that hump - lower score is good, but they run into challenges when comparing field and lab data</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 370.67px;"><img alt="" src="images/image6.png" style="width: 624.00px; height: 370.67px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">... Load-limited affects RUM tooling</span></li><li class="c2"><span class="c3">... Hard to compare RUM to CrUX. Tooling doesn&rsquo;t support what&rsquo;s collected in CrUX</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;So how are you explaining this?</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;CLS is a cumulative score, show when our beacon is fired (at &ldquo;load&rdquo; event), and see that other shifts happen after that</span></li><li class="c2"><span class="c3">&hellip; Don&rsquo;t know if this is something where we can improve how we collect metrics, or if there&rsquo;s a better way to normalize CrUX and RUM</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;CLS is full page lifecycle feature, there are also problems related to other metrics (e.g. smoothness, responsiveness) where user action is not represented in the lab.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I think there are two problems here. &nbsp;For all User Interaction dependent metrics, lab and RUM will inherently differ. &nbsp;That&#39;s fine and we&#39;ll accept that.</span></li><li class="c2"><span class="c3">... Many RUM providers today don&#39;t capture metrics for the full lifetime of the page (e.g. at onload or after). &nbsp;So we will have differences between CrUX and RUM vendors. &nbsp;We need to try to close that gap. &nbsp;I have one potential solution to that later days.</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Is the main complain lab settings vs rum data, or lab settings vs. CrUX</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;I think the later, it starts there. &nbsp;But then when looking at Lighthouse, you also see a difference.</span></li><li class="c2"><span class="c3">... Challenge comes back to how tools are quick to measure this</span></li><li class="c2"><span class="c3">... This is how analytics has always done this, there are some metrics we can capture later but we generally get everything at load-ish event</span></li><li class="c2"><span class="c3">... Reporting API is potentially a way to close that gap</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;For a full page lifecycle session, a 0.1 CLS for a 12 hour gmail session vs. a 0.1 CLS for a load page are very different experiences</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Active accumulating is not always the best measure</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;We&#39;ve had to improve our tooling, and normalize data between synthetic, CrUX, RUM</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;For Lighthouse specifically, we are working towards getting post-load data. &nbsp;Trying to work on naming the different CLS measurements here.</span></li><li class="c2"><span class="c1">Benjamin:</span><span>&nbsp;</span><span>the &quot;I don&#39;t know how to fix this&quot; is concerning</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Agree that it&rsquo;s a problem, and tools need to fix it. Maybe we can focus on the largest shifts first</span></li><li class="c2"><span class="c3">... FID - most customers pass it fine. Seems like the bar is too low, 75th %ile is far below 100ms</span></li><li class="c2"><span class="c3">... customer example: 19ms 75%ile FID, but &ldquo;JS longest task&rdquo; at 300ms, which is not great</span></li><li class="c2"><span class="c3">... So not shining a big enough light</span></li><li class="c2"><span class="c3">... LTs may be after load, wait for user interaction, so that may explain some discrepancies</span></li><li class="c2"><span class="c3">... Want LT attribution, today it&rsquo;s hard to find the source of the LT</span></li><li class="c2"><span class="c3">... FID may need to be a higher bar</span></li><li class="c2"><span class="c1">NPM:</span><span class="c3">&nbsp;Patrick will be discussing how to do LT attribution in Lighthouse and maybe we can use it here too</span></li><li class="c2"><span class="c1">Annie:</span><span class="c3">&nbsp;Folks on the team also think that the bar may be low</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;Maybe it&rsquo;s just not a problem in 75% of cases?</span></li><li class="c2"><span class="c1">NPM:</span><span class="c3">&nbsp;Problem may be elsewhere</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Display ad performance - how can we measure 3P performance</span></li><li class="c2"><span class="c3">... Discussion with a customer a few weeks ago - how haven&rsquo;t we fixed it yet?</span></li><li class="c2"><span class="c3">... Anything we could be doing about this today?</span></li><li class="c2"><span class="c3">... Otherwise, visibility into resources in iframes would be huge</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;As a RUM vendor, +1 to all that</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;For Scheduling, we see a desire from folks to control what 3Ps are doing, deprioritizing them, etc. Great to collaborate on getting metrics on this</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Server Timing, still under used by pages. Guessing that a lot of this is coming from Akamai. Fill that this is a missed opportunity</span></li><li class="c2"><span class="c3">... Call to action - are we really doing everything we can with Server Timing.</span></li><li class="c2"><span class="c3">... SpeedCurve doesn&rsquo;t yet collect it</span></li><li class="c2"><span class="c3">... WPT surfaces it, but can we do more?</span></li><li class="c2"><span class="c3">... Would love to see other CDNs surface it</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;RE CWV, have your customers reported good/bad things about the metrics, business metrics, etc?</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Yeah, got a mix. Strong correlation with FID, of bounce with LCP, but less with CLS</span></li><li class="c2"><span class="c3">... They&#39;re happy with CLS that they knew there was a problem, and now we can measure it</span></li><li class="c2"><span class="c3">... Want to collect more data on long term conversion rates, but see strong correlations with user frustration</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.z0rsadstvhrv"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1KqfH0j-OMY6kOsAyh4impB9q4OwSfX--waenzF8iFX4/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378278000&amp;usg=AOvVaw0H3SmZ_6ud9Ytf6Tp19YVr">Main Thread Scheduling APIs</a></span><span class="c24">&nbsp;- Scott Haseley</span></h3><ul class="c7 lst-kix_58jn7kl8qb33-0 start"><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Keeping high level, not diving into things as much</span></li><li class="c2"><span class="c3">... Available APIs:</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">scheduler.postTask - Prioritized task scheduling, enables coordination through priorities, controllable (cancel or change priority)</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-2 start"><li class="c9 c13"><span class="c3">Post a task and get a Promise that resolves when the task is done</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1"><li class="c9 c15"><span class="c3">TaskController has a signal that enables aborting a full class of tasks or change their priorities</span></li><li class="c9 c15"><span class="c3">Currently available in Origin Trial, and behind a flag since M82. React and AirBnB plan to start experimenting with it ASAP.\</span></li><li class="c9 c15"><span class="c3">React replaced their user-land scheduler. AirBnB use it to break up long tasks</span></li><li class="c9 c15"><span class="c3">Next steps: getting feedback from OT and see where we go</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c3">... Followup - signal inheritance</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">Folks want to inherit the signal to create subtasks that listen to priority changes</span></li><li class="c9 c15"><span class="c3">postTask + signal inheritance</span></li><li class="c9 c15"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 346.67px;"><img alt="" src="images/image2.png" style="width: 624.00px; height: 346.67px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c9 c15"><span class="c3">There&rsquo;s some risk with propagation. Inheriting the context of some tasks, but that soon degrades to &ldquo;everything is high priority&rdquo;</span></li><li class="c9 c15"><span class="c3">It&rsquo;s in the OT, but unclear if this will be part of the shipped API</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c1">Subrata:</span><span class="c3">&nbsp;How is starvation handled in this case?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Tradeoff between giving developers strict guarantees and giving the browser control. Starvation is isolated to postTask tasks. </span></li><li class="c2"><span class="c3">&hellip; First pass is strict priority order. Want to get feedback on that to see if it&rsquo;s good enough, and have metrics to measure starvation. Keeping an eye out for it</span></li><li class="c2"><span class="c3">... Other problems we&rsquo;re exploring</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">Yielding in Long Tasks</span></li><li class="c9 c15"><span class="c3">Has come up in the context of isInputPending</span></li><li class="c9 c15"><span class="c3">Currently folks schedule setTimeout/postMessage, but you may &ldquo;miss your place in line&rdquo; and it&rsquo;s not great ergonomically</span></li><li class="c9 c15"><span class="c3">Also want to reduce the penalty for yielding, enabling faster control</span></li><li class="c9 c15"><span class="c3">Otherwise, folks want &ldquo;Yield to rendering/input/network/etc&rdquo;</span></li><li class="c9 c15"><span class="c3">Initially proposed scheduler.yield(), returning a Promise which returns when the thing you&rsquo;re yielding for is done</span></li><li class="c9 c15"><span class="c3">Want to minimize scope, just for postTask, which may open up options</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-2 start"><li class="c9 c13"><span class="c3">E.g. integrating generator functions, so we could make postTasks understand generator, and turn functions there to yieldy functions</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Reminds me of the spawn pattern</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;You could imagine this changed into &ldquo;I want to yield to specific things&rdquo;. It&rsquo;s exciting for us how easy it is to insert yield points that would work with both async and sync code</span></li><li class="c2"><span class="c3">&hellip; Will be exploring that soon</span></li><li class="c2"><span class="c3">&hellip; postTask - app specific priorities</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">A lot of partners that develop their own schedulers. Continuing to do that would require building their own queues on top of postTask</span></li><li class="c9 c15"><span class="c3">One proposal is to add an option for a &ldquo;rank&rdquo; for the order of the task in the priority queue</span></li><li class="c9 c15"><span class="c3">If you have multiple parties on the page that have different ranking systems, we&rsquo;d want to be able to schedule both</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;It&#39;s unclear how you would reconcile multiple ranking systems from different parties? &nbsp;Do they all go into a single queue based on the same rank? &nbsp;Or normalize?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;If you provide a task signal, that indicates the priority can change. &nbsp;Not clear if that will work for developers. &nbsp;Need to understand what guarantees they want.</span></li><li class="c2"><span class="c3">... From browser&#39;s perspective we want freedom to schedule as needed</span></li><li class="c2"><span class="c3">... Could provide a larger domain, where everything in the domain is ranked</span></li><li class="c2"><span class="c3">... With v1, what guarantees do we provide and will that hurt us down the line</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;If you don&#39;t provide a domain, you&#39;re just relying on the signal, or some other queues?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;A signal, or there might be a default domain, simple apps would just use that.</span></li><li class="c2"><span class="c3">... 3P script scheduling:</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">Give developers some control over when 3P scripts run on main thread</span></li><li class="c9 c15"><span class="c3">Explore what is being done on main thread by 3P libraries</span></li><li class="c9 c15"><span class="c3">Control might be deprioritizing, delaying, etc</span></li><li class="c9 c15"><span class="c3">How do we prevent or mitigate a 3P task from using highest priority all of the time</span></li><li class="c9 c15"><span class="c3">IFRAMEs might be a good place to annotate what is important</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c3">... Further out: postTask priorities on async things that developers don&#39;t have control over, I/O such as IndexDB or network resources</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-1 start"><li class="c9 c15"><span class="c3">Tried prioritizing all DB tasks, showed some improvements, but unclear if this impacts on all sites in general</span></li><li class="c9 c15"><span class="c3">Allowing developers to specify priority might make sense</span></li></ul><ul class="c7 lst-kix_58jn7kl8qb33-0"><li class="c2"><span class="c3">... Can postTask be extended to microtasks? Demand from frameworks</span></li><li class="c2"><span class="c3">... After-task callbacks: being able to measure all microtasks to determine full duration</span></li><li class="c2"><span class="c3">... Async task graph tracking: May spawn multiple async tasks, useful to know for bookkeeping, measurements, task harness</span></li><li class="c2"><span class="c3">... postTask and rendering: how important is rendering compared to other work (tasks)? &nbsp;DOM R/W coordination</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Instead of just how many tasks, provide a time budget</span></li><li class="c2"><span class="c3">... Would avoid response input delay</span></li><li class="c2"><span class="c3">... Multiple very short tasks to avoid a LongTask can still starve rendering</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;We&#39;ve made some changes since then, are open to feedback and questions</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;On 3P prioritization stuff, is there a proposal ready?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Not a formal proposal yet. &nbsp;We want to take a look at the space more wholistically first. &nbsp;I can update these slides with that proposal.</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;I think it would be valuable, though it could be hard for a developer to know what 3P domains are important</span></li><li class="c2"><span class="c1">Nicole:</span><span class="c3">&nbsp;We realized we needed more data about what these 3P plugins are doing anyways. &nbsp;Took 10 and put them into a site to see what it&#39;s doing when.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Even things like URLs need some sort of opt-in from 3P frames to expose what they&#39;re loading. &nbsp;Similar to Nic&#39;s proposal for 3P frames to opt-in to parent frames</span></li><li class="c2"><span class="c3">... Controlling 3P frames is easier than to get details about what they are</span></li><li class="c2"><span class="c1">Nicole:</span><span class="c3">&nbsp;Surfacing what third parties are doing upward will just put application authors in just the same bad position they are now, managing behavior of something out of their control</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Theoretically, unless RUM providers can make that surfacing actionable</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;As a RUM provider, big request from our customers to get insights into what is causing the pain, and we could jump through those hoops</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Useful for then if there is some sort of control, we could make it actionable</span></li><li class="c2"><span class="c1">Nicole:</span><span class="c3">&nbsp;Maybe we could reach out to security folks to see what is possible.</span></li><li class="c2"><span class="c1">Nicole:</span><span class="c3">&nbsp;Maybe we should see if we can start a convo about security folks to see if it&#39;s possible</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Also a problem of when a 3P script injects into the main thread, might make it more incentivized. &nbsp;If 3P are punished for being in their own context, they will try to inject into the main context</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We shouldn&#39;t make that only possible only in the context of the frames and not main frame, then 3P will shift their work to main frame</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;We&#39;re focused on the main frame/thread as well that&#39;s competing with 1P code etc</span></li><li class="c2"><span class="c3">... example GA is doing setTimeouts for all of its things and those happening at inopportune times</span></li></ul><h3 class="c5" id="h.2wxzuvisl3kx"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1nxNFwsGqYy7WmIZ3uv_0HsSIQMSXQA9_PqlOD3V74Us/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378289000&amp;usg=AOvVaw0jtEY2n-bJ69fUUbkU38qi">Interactions and Event Timing - Nicol&aacute;s Pe&ntilde;a Moreno</a></span></h3><ul class="c7 lst-kix_nmbh00m7ya3h-0 start"><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Responsiveness: Current metric in CWV: FID</span></li><li class="c2"><span class="c3">... Does not capture &quot;end to end&quot; latency of user interaction - when user clicked till the event starting to be processed</span></li><li class="c2"><span class="c3">... Only measures the &quot;first&quot; - not great for SPAs</span></li><li class="c2"><span class="c3">... Diagram shows different points in time for a user interaction</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 349.33px;"><img alt="" src="images/image16.png" style="width: 624.00px; height: 349.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">... After a user interaction, there is the first frame, the first star above</span></li><li class="c2"><span class="c3">... Then there&#39;s other async work</span></li><li class="c2"><span class="c3">... How do we measure the &quot;Final Frame&quot;, aka the second star above?</span></li><li class="c2"><span class="c3">... Determining the &quot;end&quot; for async work requires tracking some sort of causality, would need to be a heuristic. Related to LT attribution, which needs something similar</span></li><li class="c2"><span class="c3">... Problem of aggregating, e.g. a single user interaction may correspond to a large sequence of events. E.g. tap =&gt; mouse up, mouse down, pointer up/down, and click</span></li></ul><ul class="c7 lst-kix_nmbh00m7ya3h-1 start"><li class="c9 c15"><span class="c3">Can result in over counting of taps</span></li></ul><ul class="c7 lst-kix_nmbh00m7ya3h-0"><li class="c2"><span class="c3">&hellip; Want to enable developers to track per-event metrics, but also per user-interaction</span></li><li class="c2"><span class="c3">&hellip; Proposal - adding an interactionID to PerformanceEventTiming that would be the same for events triggered by a single user interaction</span></li><li class="c2"><span class="c3">Example</span></li><li class="c2"><span class="c3">From this, via a PerformanceObserver, you would group interactions by InteractionID and get the max of those handlers</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 454.00px; height: 282.00px;"><img alt="" src="images/image7.png" style="width: 624.00px; height: 351.00px; margin-left: -62.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 300.00px;"><img alt="" src="images/image4.png" style="width: 624.00px; height: 300.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c1">Alternatives:</span><span class="c3">&nbsp;New Interactions API (would require yet another API)</span></li><li class="c2"><span class="c3">... Polyfill on top of EventTiming: events with &quot;close&quot; timestamps would be in same interaction</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Very important space to solve the end-to-end measurements, as well as the interaction ID. Tried to tackle this with existing APIs. </span></li><li class="c2"><span class="c3">&hellip; used EventTiming API without addressing the multiple event issue, and then combined Element Timing to measure the added image&rsquo;s paint timing.</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Wonder how different that is from the duration value that&rsquo;s already available in EventTiming. That captures a timestamp to the next paint after the event.</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;The problem is that it&rsquo;s not guaranteed that the relevant paint would be in the next frame</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;In the scenario you&#39;re describing, with a specific element you want to measure, this makes sense. &nbsp;We&#39;ll talk about more various task tracking in context of LongTask attribution later. &nbsp;Can bring that back to coalescing of multiple events to a single user interaction.</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Important for us to address as well.</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;For mPulse interaction tracking, tracking through FID. See a lot of value in tracking async tasks triggered by events.</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Tracking FID as well. With attribution, this is very helpful. Started tracking other input things, like when user input happens, but not sure it&rsquo;s super helpful, because applications vary on that front. Keen on getting more timing around event handling.</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;Aggregation of duration and filtering by event id - when we stagger events, do we want to take the start of the first event and the end of the last one?</span></li><li class="c2"><span>Nicol&aacute;s</span><span>: Open to ideas about what we should be measuring. Feedback welcome on </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/WICG/event-timing&amp;sa=D&amp;ust=1607595378295000&amp;usg=AOvVaw1pFs7gFER3FnuJhk6BTE2h">https://github.com/WICG/event-timing</a></span><span class="c3">&nbsp;</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;Start of pointerdown till end of click in the example seems to be what we&rsquo;d want</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: We care about the user&rsquo;s interaction until the thing is completed.</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;It&rsquo;s possible with your proposal, just not a simple oneliner</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Currently only surface slow events</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;You&rsquo;d still have a problem you can&#39;t necessarily map from a pointerdown to a click event</span></li></ul><ul class="c7 lst-kix_nmbh00m7ya3h-1 start"><li class="c9 c15"><span class="c3">Do we want to count the duration the user help their finger to the screen? Maybe</span></li></ul><ul class="c7 lst-kix_nmbh00m7ya3h-0"><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Yeah, unclear what we want to measure with long taps. With interactionID could let you know it was a long tap. &nbsp;Not sure if the event surfaces that.</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;How would that work with a combination of events, e.g. pointerdown to a mouse-move, dragging</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: That&#39;s a good question, the discrete events in EventTiming, but for a drag how would you classify the interaction</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Sometimes you care about the pointer up event, not the pointer down. But the API with the interaction ID enables you to do that</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: Maybe until the finger is lifted, that&#39;s how long the interaction is tracked</span></li></ul><h2 class="c16" id="h.shnyygeax07n"><span class="c10">Tuesday October 20</span></h2><h3 class="c8" id="h.nh9xf4k3tm9p"><span>Prerendering</span><span>&nbsp;</span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1N_VqjaD5EqnMd9doTEsa8YFTn5ben68oVPk9Pqfxgr0/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378298000&amp;usg=AOvVaw2ygu5JxYbN7ru9IvUEZs_i">[pre* with author support]</a></span><span class="c24">&nbsp;- Jeremy Roman</span></h3><ul class="c7 lst-kix_xdww37wt89zq-0 start"><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;Looking at bringing back pre-rendering</span></li><li class="c2"><span class="c3">... Requires three parts: Trigger, Opt-in, Behavior Changes</span></li><li class="c2"><span class="c3">... Behavior Changes: Limit nuisance behavior and limit cross-site tracking</span></li><li class="c2"><span class="c3">... via uncredentialed pre-navigation fetch</span></li><li class="c2"><span class="c3">... Sites cannot access their unpartitioned storage before navigation</span></li><li class="c2"><span class="c3">... Opt-In: Site may need to &quot;upgrade on navigation&quot; if a user is already logged in after un-credentialed pre-navigation fetch</span></li><li class="c2"><span class="c3">... Trigger: Referring page needs to indicate that pre-navigation fetching is safe from unwanted side-effects, resource is compatible, and user is likely to navigate. Link rel prerender is the previous iteration of this</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;this is all pretty early. Portals came up with the concepts, but then realized it&rsquo;s more general</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Something I find interesting about upgrade path is that it can encourage cacheable static upgrade HTML that can upgrade itself to a customized experience</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;most sites already have a logged out view, and they can add a bit of JS to modify that state</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;What does the upgrade flow look like?</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;exact shape of the API depends on how the API evolve and how storage access and other adjacent APIs evolve</span></li></ul><ul class="c7 lst-kix_xdww37wt89zq-1 start"><li class="c9 c15"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/jeremyroman/alternate-loading-modes/blob/da06f15f4c547a0c6a1616666f4fb361109e899b/browsing-context.md%23javascript-api&amp;sa=D&amp;ust=1607595378301000&amp;usg=AOvVaw2Vby3hPEnlmziVVHOhjvQC">current API shape</a></span><span class="c3">&nbsp;</span></li></ul><ul class="c7 lst-kix_xdww37wt89zq-0"><li class="c2"><span class="c3">&hellip; Ultimately what authors want to do here is get notified when storage is available, and then load the data that&rsquo;s dependent on personalized state.</span></li><li class="c2"><span class="c3">&hellip; If the entire application is personalized there&rsquo;s little you can load ahead of time, but static sites may be different. Visiting e.g. Wikipedia, most of the content would be the same for all users, and only a small number of components would change</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;thinking there would be some event that indicates that state change: prerender to render or storage availability, etc.</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;trying to figure this out. There are APIs for the different changes: permissions API that will tell you if you&rsquo;d be auto-denied when prerendered, storage access in many browsers. Unclear if we should tell people to use these signals individually or bundle them. Early days still.</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;If a site doesn&rsquo;t declare &ldquo;I can upgrade&rdquo; and we fetched it, will we throw it out?</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;If the user has local credentials, we cannot use the response</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;and if the user doesn&rsquo;t?</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;Maybe. I don&rsquo;t see why we couldn&rsquo;t</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;we would still be unable to use the rendering, and it was rendered with shut down APIs</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;yeah, but we could potentially use the response bodies</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;If a site is static and credential-less, they&rsquo;d still have to opt-in and their upgrade would do nothing</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;yeah, as we can&rsquo;t determine that from the client side</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;You&rsquo;re talking about reusing the renderer. The original prerender dies because of excessive resource usage. How are things different today?</span></li><li class="c2"><span class="c1">Kinuko:</span><span class="c3">&nbsp;We still worry about resources, but we have throttling infrastructure that can enable us to prerender without consuming too many resources</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;UAs that run on devices that have no resources for that, they can always do nothing with prerender hints. Hope that pages would identify that they are prerendered and use less resources while prerendered</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;but that was the case before. The work on the site&rsquo;s side is the same. Was there adoption last time</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;I think we cannot depend on sites. The shift in thinking came when we implemented BFCache. We also had background tabs. This is extending the same principle - keep things around that will improve UX in the future.</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;We also put more effort on sites caring about performance - e.g. CoreWebVitals. But agree that we can&rsquo;t rely on sites</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;the performance impact when it works can be awesome. But worried that it may mostly work for lightweight sites and SPA/SSR would send down the credentialed experience and not want to do the credential transitions on the client side.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;implications towards performance measurement?</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;started thinking about it, but no conclusions yet</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;pages still want to know when they prerender, but also need to know if that made the UX super fast. So we need 2 different metrics: the traditional load timings that may have happened in the background and what the user actually experiences, which could be 0 or close to 0. Still don&rsquo;t know how it will be manifested</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Couldn&rsquo;t agree more and will be talking about related issues.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;One question to other browser vendors around non-credentialed prerender coupled with lack of access to localstorage. In the past we talked about privacy preserving prefetch and this is in a way an extension to that. Would that be something that is implementable?</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;Implementable yes, but a little strange. Initial thought would be do a load with credentials and storage in its own partition.</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;Reason for no-storage is that you do need to eventually transition to first party partition. E.g. You&#39;d need to migrate/merge two IndexDBs</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;In our implementation, if you&#39;re on a.com and you prerender b.com, in b.com&#39;s partition, there would be no problem if it becomes the main frame&#39;s content</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;If you load b.com in partition, it&#39;s not the partition that stores the user&#39;s current cookies and credentials, the user doesn&#39;t see themselves as logged in when they transition</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;May be a difference between cookie partitioning in Webkit and Chromium. In WebKit I see no problem and no need for this transition</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;This is new technology. There&rsquo;s no way today to take an iframe and make it the top-level page. Without a transition, there could be a situation where the user has 2 tabs to the site, but will only be logged in in one of them</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;If you&rsquo;re prerendering something, the current page won&rsquo;t have access to its contents, right? There&rsquo;s a difference in our thinking here.</span></li><li class="c2"><span class="c1">Domenic:</span><span>&nbsp;wrote up our </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/jeremyroman/alternate-loading-modes/blob/da06f15f4c547a0c6a1616666f4fb361109e899b/browsing-context.md%23privacy-based-restrictions&amp;sa=D&amp;ust=1607595378306000&amp;usg=AOvVaw3X8KCXRJCmv3lYle6Wx1hL">threat model</a></span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Maybe the difference comes from a model that works both from prerendering and portals</span></li><li class="c2"><span class="c1">Jeremy:</span><span class="c3">&nbsp;I think this just exists with prerendering</span></li><li class="c2"><span class="c3">... If you do fetch with credentials from a.com to b.com, it allows you to essentially do a subresource request with credentials</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;We&#39;re designing this to align more to Safari&#39;s model that Chromium&#39;s current model</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We can discuss in upcoming WG call or offline on Github</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Whenever you do a prerender you do a cross-origin request in a separate state each time, correct? &nbsp;Are there timing attacks?</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;There are timing attacks possible which is why we&#39;re trying to partition here. &nbsp;There are probably other attack here.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Something we can look into.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Can we talk about visibility aspects?</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.mt1aoksixjtv"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1IuE9ZX0dCHj7z-alCDQ4iURFxeHp5HqnRyyogvM11BY/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378308000&amp;usg=AOvVaw0v7BmhVgBKr8-cqmuwvQ1X">Prerender PageVisibility</a></span><span class="c24">&nbsp;- David Bokan</span></h3><ul class="c7 lst-kix_vw67r1bqbxva-0 start"><li class="c6"><span class="c1">David:</span><span class="c3">&nbsp;Need some way to signal to a page it&#39;s been pre-rendered</span></li><li class="c6"><span class="c3">... Is it hidden enough? &nbsp;Some content shouldn&#39;t load/run in prerender, e.g. ads, analytics</span></li><li class="c6"><span class="c3">... Content could be visible, needs to be up to date, e.g. portal</span></li><li class="c6"><span class="c3">... Open Questions</span></li><li class="c6"><span class="c3">... Compatibility: Check for visibilityState==&quot;prerender&quot;, some pages check for if-visible-else, which could break</span></li><li class="c6"><span class="c3">... Will require opt-in so compat is nice-to-have but not critical</span></li><li class="c6"><span class="c3">... What does document.hidden return</span></li><li class="c6"><span class="c3">... Portals: Allow showing a preview of a prerendered page, differs from prerender as it might be visible to a user</span></li><li class="c6"><span class="c3">... Pages could be put into portal. &nbsp;Can go from visible to in a portal</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Portal idea might get us out of the jam of some visibilityState and App Switcher</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;We have an explainer for Portals, but it&rsquo;s being rebased on top of prerender explainers</span></li><li class="c6"><span class="c1">David:</span><span class="c3">&nbsp;A portal kind of looks and feels like an IFRAME, where it starts out embedded on the page, but it&#39;s a link where you can see a preview of the navigation. &nbsp;Curious about app launcher discussions?</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;We&#39;ve had some discussions whether a page is visible or hidden if you&#39;re in App Switcher, that problem may have relevance to Portals</span></li><li class="c6"><span class="c1">Michal:</span><span class="c3">&nbsp;Our discussion around App Switcher is if we&#39;re going to move off a two-state from visible/hidden, what else happens there</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;Content is &quot;viewable&quot; but it&#39;s not the top-level document. &nbsp;If we had a &quot;preview&quot; state that might help with both.</span></li><li class="c6"><span class="c1">David:</span><span class="c3">&nbsp;In a portal you&#39;re not able to interact with content, more of a preview</span></li><li class="c6"><span class="c1">Michal:</span><span class="c3">&nbsp;&quot;Non-interactive&quot; was the proposed state</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Having a new visibility state for Portal might be a smoother path forward</span></li><li class="c6"><span class="c1">NPM:</span><span class="c3">&nbsp;Isn&#39;t visibilityState determined on the page level right now? &nbsp;Say if you have an iframe not in the viewport, it will still be considered visible.</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;People&#39;s intuition often think of portals as visible, but it&#39;s more aligned to a popup window that&#39;s overlaid on the page. &nbsp;Visibility state separate from the document.</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;Seems like we have multiple states that have overlap. For pre-render we could have hidden content, but we also need to know if it&#39;s prerendered to not do various things. &nbsp;It&#39;s both hidden and non-interactive, where one is a subset of the other. &nbsp;We need some way to mix-and-match those. Is the best path 3 or 4 states with overlap between them, or orthogonal signals we can mix together?</span></li><li class="c6"><span class="c1">Michal:</span><span class="c3">&nbsp;That came to mind as well because so many sites check for &quot;not visible&quot; as a hint for hidden, etc. &nbsp;Maybe one way to get out of that bind is to think if visible/hidden is appropriate for all of those cases, and we have a separate visible type, such as for App Switcher</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;I could imagine a bunch of different boolean switches: app switcher, portal, background tab, etc. &nbsp;Could make a matrix of all of those and see if there&#39;s overlap and if we want a bunch of booleans or a big enum</span></li><li class="c6"><span class="c1">Jeremy:</span><span class="c3">&nbsp;the other aspect RE the ideal design is how can we reasonably get from the current to that ideal design with relation to existing content</span></li><li class="c6"><span class="c1">David:</span><span class="c3">&nbsp;The other interesting thing is what would you consider the visibility state for a portal on a page. &nbsp;It&#39;s drawing content and you want it to be ready. &nbsp;But if you &nbsp;have a portal in a BG tab you don&#39;t want it to do a lot of work. &nbsp;Don&#39;t want it tied to top-pages visibility, because it&#39;s a timing communication channel, if you switch tabs and both get the visibility state at the same time.</span></li><li class="c6"><span>Nicol&aacute;s</span><span class="c3">: can&rsquo;t you do that with iframes?</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;IFRAMEs get their own storage partitions, while portals do not</span></li><li class="c6"><span>Nicol&aacute;s</span><span class="c3">: Makes it hard to reason about the visibility state of a portal</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;For a visible portal, you&rsquo;d want it to animate, where for an invisible portal you wouldn&rsquo;t want that.</span></li><li class="c6"><span class="c1">NPM:</span><span class="c3">&nbsp;There&#39;s two general use cases, (1) is know whether you want to execute some amount of work and (2) tracking performance of paint metrics</span></li><li class="c6"><span class="c3">... Want portal to count as having paint metrics when it&#39;s still a portal, but hard if we can&#39;t tell if it&#39;s backgrounded</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;Might be better to always think of it as backgrounded. It&rsquo;s ok if your preview doesn&rsquo;t have animations. Extra preview on top of prerendering, and a prerendered page is not visible</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Does the pre-rendered page never change?</span></li><li class="c6"><span class="c1">Jeremy:</span><span class="c3">&nbsp;We don&#39;t envision taking a single screenshot, we allow paints to happen and frames to be generated. &nbsp;UA could do that at a lower rate if desired.</span></li><li class="c6"><span class="c1">Michal:</span><span class="c3">&nbsp;but that conflicts with the goal of treating it as hidden, when some pages avoid e.g. background play</span></li><li class="c6"><span class="c1">Jeremy:</span><span class="c3">&nbsp;you want to avoid BG play when users don&rsquo;t see it. But you don&rsquo;t want the page to no show up at all. I&rsquo;d imagine most people not do delay attaching DOM events on page visibility.</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;and to be clear, you do have to opt in. So the site should see they are rendering reasonably when portaled.</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;One conflicting requirement in preview state is for tab switcher and app switcher case, we do want animations and video to continue to play.</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;But we don&rsquo;t know what the implications are on HTML</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;We&#39;ve been thinking of prerendering things as browsing contexts, maybe app switchers are browsing contexts in some level. &nbsp;But largely for privacy reasons we don&#39;t want portals to know they&#39;re visible and doing animations and stuff.</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;Your concept of creating a matrix with all states sounds like the right next step.</span></li><li class="c6"><span class="c1">Michal:</span><span class="c3">&nbsp;On the previous topic of prerender, I don&#39;t know if Benjamin had an opinion.</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Don&#39;t have anything to say, initial impression is better to start with something simple, the localStorage thing is complex</span></li><li class="c6"><span class="c1">Alex:</span><span class="c3">&nbsp;I see the wisdom in not allowing localStorage and credentials, that could be problematic</span></li><li class="c6"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Do we know what types of sites got the most benefit from prerender?</span></li><li class="c6"><span class="c1">Kinuko:</span><span class="c3">&nbsp;Good question, there were a few pages that had issues. &nbsp;I don&#39;t have data if there was a significant difference between sites.</span></li><li class="c6"><span class="c1">Yoav:</span><span class="c3">&nbsp;There are also fundamental issues between credentialed content pre-rendering and non-credentialed prerendering. Credentialed prerendering would change site state (e.g. log off user), Non-credentialed problems would be with users missing their credentials because the site didn&rsquo;t do the transition work</span></li><li class="c6"><span class="c3">... Are other browsers doing any prerendering? URL-bar based one?</span></li><li class="c6"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;When the user is typing the URL, there&#39;s no tracking, so can prerender the site with credentials</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;What if a user types a user like example.com/logout and you prerender that with credentials</span></li><li class="c6"><span class="c1">Alex:</span><span class="c3">&nbsp;Probably issues with edge cases like that</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;Some things like to shut down during prerendering like speech synthesis APIs. We want to produce an exhaustive list of APIs that we should shut down, which will be useful for browser-initiated prerendering as well. Not mandatory, but hopefully useful</span></li><li class="c6"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;if the user types the URL, there&rsquo;s no need for non-credentialed prerendering</span></li><li class="c6"><span class="c1">Domenic:</span><span class="c3">&nbsp;Two variants, same-origin and cross-origin, where cross-origin does all privacy protections, but annoyance prevention is relevant for both</span></li><li class="c6"><span class="c1">Kinuko:</span><span class="c3">&nbsp;Visibility discussion could be useful to that case as well</span></li><li class="c6"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Things like auto-play audio probably don&#39;t exist in UAs anymore, but there are also probably other edge cases for things to disable</span></li><li class="c6"><span class="c1">Jeremy:</span><span class="c3">&nbsp;Things that are behind user-gestures are fine, but there are some APIs which aren&rsquo;t protected by that.</span></li></ul><h3 class="c5" id="h.vhoche6vbj9x"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/12qJ5RwS32TJ6OVZfs64X34dRzvwhq9iK2hwSP-Z6AXE/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378319000&amp;usg=AOvVaw339mftpr_jLOzpqP38o_1g">SPA reporting</a></span><span class="c24">&nbsp;- Michal Mocny</span></h3><ul class="c7 lst-kix_pyp8natv44as-0 start"><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;SPA dynamically rewrite the page content instead of navigating, commonly use frameworks, use hash fragments or history API to update URL</span></li><li class="c2"><span class="c3">&hellip; RUM metrics and tools typically target traditional loads, and synthetic tools are also not great</span></li><li class="c2"><span class="c3">&hellip; Either in the dark on these sites, or get the wrong picture</span></li><li class="c2"><span class="c3">&hellip; types of SPA navs: full page recreation, content swapping, component update, infinite scroll</span></li><li class="c2"><span class="c3">&hellip; Loading: dynamically load what you need, large common template, preload everything (common with scripts), </span></li><li class="c2"><span class="c3">&hellip; initial load: client side rendering vs. SSR + hydration</span></li><li class="c2"><span class="c3">&hellip; subsequent loads: interaction vs. automatic</span></li><li class="c2"><span class="c3">&hellip; frameworks have signals for route transition starts and visual updates</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-1 start"><li class="c9 c15"><span class="c3">Coverage is partial</span></li><li class="c9 c15"><span class="c3">&quot;Soft done&quot; when all initial work has been started, but not yet done</span></li><li class="c9 c15"><span class="c3">Async work may not be captured</span></li><li class="c9 c15"><span class="c3">zone.js tried to link async work, but may not work with modern async JS </span></li></ul><ul class="c7 lst-kix_pyp8natv44as-0"><li class="c2"><span class="c3">&hellip; some RUM frameworks mark route starts, listen to network usage &amp; DOM updates</span></li><li class="c2"><span class="c3">&hellip; We also have UserTiming. Conventions there could help</span></li><li class="c2"><span class="c3">&hellip; Automatic marking via heuristics?</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-1 start"><li class="c9 c15"><span class="c3">If we had conventions and marks, that could help when testing heuristics.</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-0"><li class="c2"><span class="c3">...Work on revamp of the history API - maybe we can provide an API to provide a well-lit path to give us something to hook onto when measuring</span></li><li class="c2"><span class="c3">&hellip; Measurement for SPA</span></li><li class="c2"><span class="c3">&hellip; Responsiveness - Event Timing can give us data on long event durations. Could provide onload?</span></li><li class="c2"><span class="c3">&hellip; We&rsquo;d also want to track the next input, similar to FID</span></li><li class="c2"><span class="c3">&hellip; There&rsquo;s also the question of attribution</span></li><li class="c2"><span class="c3">&hellip; next paint we get from event timing, but interested in FCP or LCP</span></li><li class="c2"><span class="c3">&hellip; gets problematic with partial updates: the first paint is always contentful, or maybe we only want to count paints for new content</span></li><li class="c2"><span class="c3">&hellip; visual stability - layout instability is fine, but CLS is cumulative, so ignores softnavs</span></li><li class="c2"><span class="c3">&hellip; One difference between page load and softnavs is that layout shifts that happen post load would get a signal of hadRecentInput, but new content that gets added as part of a softnav and then shifted is similar to a page load, even if it happened within the 500ms timeout after user input. </span></li><li class="c2"><span class="c3">&hellip; Transitions from MPA to SPA - </span></li></ul><ul class="c7 lst-kix_pyp8natv44as-1 start"><li class="c9 c15"><span class="c3">SPA navs measure more soft navs, but less page loads</span></li><li class="c9 c15"><span class="c3">Faster transitions, but slower page loads</span></li><li class="c9 c15"><span class="c3">Transition causes many things to change at once, so hard to find causes</span></li><li class="c9 c15"><span class="c3">Fewer page loads result in worse caching</span></li><li class="c9 c15"><span class="c3">&ldquo;More pageviews&rdquo; - may be a result of transitions</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-0"><li class="c2"><span class="c3">&hellip; Attribution - ideally, we could report on each route change and reset metrics</span></li><li class="c2"><span class="c3">&hellip; But you can&rsquo;t necessarily report the same metrics</span></li><li class="c2"><span class="c3">&hellip; Should we blend the metrics with their page load equivalents?</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-1 start"><li class="c9 c15"><span class="c3">Similarity to BFCache and visibility changes</span></li><li class="c9 c15"><span class="c3">Many fast post load navs don&rsquo;t compensate for one terrible first load</span></li><li class="c9 c15"><span class="c3">Bounce rates are impacted more by the initial page than by transitions</span></li><li class="c9 c15"><span class="c3">Distribution may change</span></li></ul><ul class="c7 lst-kix_pyp8natv44as-0"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;first page is important, but isn&rsquo;t that the same for MPA?</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;yes! performance is always a distribution. SPA laid is not the same of full page load, but it&rsquo;s important to segment. Question for Pat Meenan about SPA and synthetic, because when you script something in WPT, LCP is still being reported for SPA navigations. Was just on a call with a customer that is moving to a SPA, but interested when the LCP/product image paints after the softnav. So they rely on synthetic metrics.</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;In WPT, LCP may trigger if the largest in the new loads is larger than the previous loads. Element Timing is the only real way to instrument today</span></li><li class="c2"><span class="c3">&hellip; render metrics would be relative to the state of the SPA</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;LCP candidates don&rsquo;t get reported after interaction, no?</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;that would work if the routes are triggered by script, not input</span></li><li class="c2"><span class="c1">Pat:</span><span class="c3">&nbsp;yeah, that&rsquo;s how it works</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;For CLS, is this something that can be cleared?</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;CLS is not reported, so libraries can calculate it the same way Chrome does. But there&rsquo;s work underway to normalize it over time and across routes</span></li><li class="c2"><span class="c3">&hellip; If we start attributing to URL, we&rsquo;d want to cut it per route</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;that&rsquo;s what we do with Boomerang</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Depends if you want to match CrUX or improve attribution</span></li><li class="c2"><span class="c3">&hellip; Back to comparing initial load for MPA vs. SPA, there&rsquo;s definitely a difference between first load and reloads, but suspect that SPAs would have bigger differences. Cliff mentioned that they do separate that out and dig deeper. Do you find it important to separate the metrics or blend them.</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;transitioning to SPA replaces traditional page views, so need to measure holistically</span></li><li class="c2"><span class="c3">.. the answer is it depends, but having the ability to separate that matters</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;biggest concern is that the entr point for a website is paying the cost upfront and all future routes are near instantaneous. Blending is weird here</span></li><li class="c2"><span class="c3">Noam R: you need to picture both. You want the first load for business impact and subsequent loads to better understand the performance of the full user flow.</span></li><li class="c2"><span class="c3">&hellip; interesting to look at loads in the same session in MPA vs. SPA</span></li><li class="c2"><span class="c3">&hellip; SPA would give you better results in those cases</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;For SPAs, having the site fetch all possible content on first page so other pages are faster is something you can also do with MPAs with prefetch/etc</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;thinking of cold vs. warm cache, we don&rsquo;t really do much about that today. But the same is true for soft navigation, some of their resources may be cached. Important to distinguish page load types</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;the best page load is no page load - so is that a perf regression of an improvement?</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;We&rsquo;ve always discussed SPAs, super clear that this is something that&rsquo;s needed. Main question - will we require developer annotation, new history API, etc? Also, what metrics do we want to surface - FP, FCP, LCP, FID?</span></li><li class="c2"><span class="c1">Steven:</span><span class="c3">&nbsp;working with SPAs for 5 years now, and need an API to say &ldquo;we&rsquo;re doing a softnav&rdquo; to reset all the performance metrics. For navigation browser know things that they don&rsquo;t know for SPAs. Would love all the metrics to track specific SPA pages that need improvement</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;How do you signal?</span></li><li class="c2"><span class="c1">Steven:</span><span class="c3">&nbsp;today we do that in our library to reset the library instrumentation, but not the browser metrics. We change the URL, but heuristics may get it wrong, because the timing can change. Would love an API.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Event Timing reports on all long events, FID can be polyfilled, but for first inputs after a transition, you want it even if it&rsquo;s fast, so it makes sense to reset in those cases and report the first event after softnavs. </span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;annotating the SPA navigation requires something different from Event Timing. API that changes the URL, e.g. discussions about a new Navigation api that can fix history API as well enable monitoring. Requires URL changes that are not suited for Event Timing</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;issues around UX. Also, the history API is not great. Separate from that, if you want to support opening new tabs + client side routing requires a lot of work. Proposals to fix that. It wouldn&rsquo;t measure on its own, we still have to answer all these questions.</span></li><li class="c2"><span class="c3">&hellip; hardest for me to think through paint - can we just do the same things we do for the initial paint? Or should we just care about the new content?</span></li><li class="c2"><span class="c3">Noam R: If we go with the application clearing the metrics, the application can use Element Timing for something finer. Cannot rely on the history API, but can allow the application to explicitly reset the metrics.</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Couldn&rsquo;t we tell during the navigation state, when we started the event and when the last layout shift happened and ignore it if the timestamp was before the start of the SPA navigation. Wouldn&rsquo;t requiring clearing anything, you could still mark a &ldquo;next contentful paint&rdquo; or trigger a new LCP. Doesn&rsquo;t seem that complex to do today.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;You&rsquo;re right that you could just use the nav timestamps to slice a session. For paint it&rsquo;s different. I like Noam&rsquo;s suggestion, but now you&rsquo;re measuring different things</span></li><li class="c2"><span class="c3">Noam R: we can call it &ldquo;contentful paint&rdquo;</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;It&rsquo;s the first contentful paint after the SPA navigation</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;even without changing the name we can easily distinguish between one and the other, based on timestamps. Open question with paint metrics is whether we can report them for arbitrary things, from a security perspective. Killing :visited would go a long way to make that reasonable, but not sure that covers everything</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;same process cross-origin iframes can also leak things</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;if you have a cross-origin image you can get information on based on their painting times</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;is the idea to do something so developers are doing as little work as possible and get that out of the box? Or do we want a common way for developers to annotate so that we can report it everywhere?</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;One idea is to come up with a User Timing convention, get the frameworks to speak the same language and hook into that. Relies on developer hints, so we&rsquo;d have to see</span></li><li class="c2"><span class="c3">&hellip;. The next step is for that to inform better heuristics</span></li><li class="c2"><span class="c3">&hellip; and finally with the navigation API, it could restrict abuse: no reason to use it too frequently - only be used in places where top-level navigations are being used today</span></li><li class="c2"><span class="c3">&hellip; So other than just identifying - what do we measure and what do we do with it</span></li><li class="c2"><span class="c3">&hellip; Good to hear you want both blended view and separate first load view</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;This has come up and we will hear more from it. Web Vitals is still new, but it will come up</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;For our customers, they can segment hard navs from soft navs, obvious that for soft navs the metrics are not there, and we have to educate them. Would be great to have a consistent view and metrics</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;one concrete takeaway - maybe have the default be blended for MPAs and segmented for SPA. Would that minimizes surprises?</span></li><li class="c2"><span class="c1">Cliff:</span><span class="c3">&nbsp;Sounds like a good blog post</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Would be useful to better understand use-cases here with concrete examples: React app, twitter, etc and study what they&rsquo;re doing.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I looked into that. Maybe we can have a session on a call to go over such an example.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Similarly, we can hear from e.g. SalesForce how they are measuring now. E.g. some apps change the URL after the navigation. There are multiple ways to write routers, etc. SPAs can also do partial navigations. Would be interesting to see ways that apps consider navigations. Not sure if there&rsquo;s agreement there.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Tried to show this. Also history updating is a single moment in time, but some apps load pages through async processes.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;There&rsquo;s also an in-app prefetch case, where they fetch content ahead of time. Specifically to SPAs we need to be able to measure the things that happened before the navigation.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;in the conversation on prerendering, Domenic mentioned that they want to measure both prerendering and the user experience. I haven&rsquo;t previously thought about attributing the prerender work to the cost of the future route. Right now, the thing that&rsquo;s doing the prerendering is the one to which the cost is attributed. If we&rsquo;re using browser features for prerendering, that may make it easier to attribute the cost.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;AI to kick-off repo to cover the problem first, collect use-cases, properties can contribute from their experience what they&#39;re trying to measure</span></li><li class="c2"><span class="c3">Noam (in chat): I would give +1 to Steven&#39;s idea of an API which allows the app to notify that a &quot;soft navigation&quot; occurred. Relying on URL/history change is probably not sufficient for some apps.</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.wp52ifyio7ww"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1RuQkoCmWPemOvpc89rZmVv11saPy4HVZrF5BNxtzf6w/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378334000&amp;usg=AOvVaw0qCWG8d_jd1wspZQV4z62J">BFCache Reporting</a></span><span class="c24">&nbsp;- Yoav Weiss</span></h3><ul class="c7 lst-kix_b02qw36i6z2v-0 start"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We want to align user-experience metrics including BFCache</span></li><li class="c2"><span class="c3">... Fire new entries for BFCache rather than overwrite old entries/timestamps</span></li><li class="c2"><span class="c3">... Single time origin for all navigations</span></li><li class="c2"><span class="c3">... Option 1: Another NavigationTiming entry, nicely uses NT array, no new entry types</span></li><li class="c2"><span class="c3">... Compat questions, does anyone look at non-[0]th entry? &nbsp;0.125% of Alexa 100K touch a second entry, most loop over all entries. &nbsp;None relied on being exactly 1 item.</span></li><li class="c2"><span class="c3">... Downsides: Have a NT entry with a lot of 0-value properties (related to load time of resource)</span></li><li class="c2"><span class="c3">... [code example]</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 356.00px;"><img alt="" src="images/image13.png" style="width: 624.00px; height: 356.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">... Option 2: New type of PerformanceEntry, doesn&#39;t include all of the zero&#39;d values but contains the startTime</span></li><li class="c2"><span class="c3">... Option 3: New entry, also has pointers to pains/lcp/longtasks/etc. &nbsp;But at the time this entry is created, we don&#39;t have all these times necessarily</span></li><li class="c2"><span class="c3">... Option 4: PerformanceObserverEntryList on the entries to get associated ones</span></li><li class="c2"><span class="c3">... &quot;It&#39;s weird&quot;</span></li><li class="c2"><span class="c3">... How does it fit in with other observers</span></li><li class="c2"><span class="c3">... Favorite as Option #1: compatible, fits with current API shape</span></li><li class="c2"><span class="c3">... If so, should we also use it for other navigation such as SPA navs</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;In your testing, when did sites check the entire array</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;During page load process, I looked at the code samples but didn&#39;t debug through them</span></li><li class="c2"><span class="c3">... Those sites may not even see those BFCache navigation because it happens after the point in time they&#39;re collecting those metrics</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;Is there anything else to track here as part of the duration, I&#39;m assuming there&#39;s non-zero work here? &nbsp;Is there anything we need to measure?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We&#39;d want to kick off FCP, LCP, FID, etc as well in that scenario, filtered to the timestamp</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Firefox notes when BFCache is used to restore, but we don&#39;t note a duration. &nbsp;</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Would it be reasonable to re-fire paint entries and FID in case of restore?</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Possible yes</span></li><li class="c2"><span class="c3">... We&#39;re more interested in when cache is used</span></li><li class="c2"><span class="c1">Sean:</span><span class="c3">&nbsp;One thing I noticed is that all proposed options look different in what they&#39;re reporting. &nbsp;What problems do we want to solve?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I don&#39;t think they&#39;re different in terms of what they&#39;re reporting, main thing is that a navigation happened, and at the point it happened. &nbsp;Secondarily, we want to re-fire entries and filter them based on the start time of that BFCache nav.</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.dnfpgep5a3iw"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/18DfHjVoL88DXw0cseFEkCIpiIUA0E_rSkEsRjY9rCPw/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378340000&amp;usg=AOvVaw0nFRe9S1J1wdwK4O0Jv9CS">isInputPending update</a></span><span class="c24">&nbsp;- Andrew</span></h3><ul class="c7 lst-kix_q3j1f64dhj6y-0 start"><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Everyone&#39;s favorite boolean</span></li><li class="c2"><span class="c3">... Recap: Was called shouldYield, hasPendingUserInput, now isInputPending</span></li><li class="c2"><span class="c3">... Chrome 87+ Origin trial in 2019</span></li><li class="c2"><span class="c3">... Overview: Way to remain responsive for work that doesn&#39;t want to yield</span></li><li class="c2"><span class="c3">... Permits yielding less frequently if unnecessary</span></li><li class="c2"><span class="c3">... Why? &nbsp;Input only because most display blocking work is due to input</span></li><li class="c2"><span class="c3">... It does block painting/network and that&#39;s OK, not a substitute for yielding</span></li><li class="c2"><span class="c3">... FB measurements and partners show it can save time and throughput by yielding only to input, throughput up 25% from one partner</span></li><li class="c2"><span class="c3">... Interaction with LongTask API: Ideas to adding annotations to LT entries</span></li><li class="c2"><span class="c3">...</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Can&#39;t say a session is bad because it had a LT, it might&#39;ve been bad when there&#39;s user input</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;Tricky cases are when others are using isInputPending for yielding, but some may be using isInputPending for other cases or not yielding</span></li><li class="c2"><span class="c3">... Let people register for a different LongTask entry for those with isInputPending calls</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Introduces the idea of a &quot;sanctioned&quot; LongTask</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Problem coming in with Lighthouse, deadline with rIC. &nbsp;They may be checking the deadline but doing it so frequently. &nbsp;Maybe they check the rate at which they check isInputPending.</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Interesting, though you could be checking it as frequently as you want but if you may not ever do anything based on that signal</span></li><li class="c2"><span class="c1">NPM:</span><span class="c3">&nbsp;Maybe in LongTasks, an array of timestamps for isInputPending calls</span></li><li class="c2"><span class="c3">...</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;It would be interesting to mash wasInputPending with isInputPending calls to see if they reacted to input</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I know there are some RUM tools using TBT, and ...</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;When you have moderate data there are cases where LongTasks give you data that you might not see otherwise</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;The fact that the page called isInputPending gives confidence perhaps</span></li><li class="c2"><span class="c1">NPM:</span><span class="c3">&nbsp;If it was a 2 second LT and they called it at the beginning or ending, that&#39;s not a good UX</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Comes back to wondering if any annotation is useful?</span></li><li class="c2"><span class="c3">... </span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;InputStarved signal, where isInputPending was checked but it was more than X milliseconds before they yielded</span></li><li class="c2"><span class="c3">... Will take some of these suggestions to Github issue</span></li><li class="c2"><span class="c3">... Yielding to input: If yielding, how? setTimeout()/postMessage(), versus scheduler.yield(), or something new?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;... (may not cover this case exactly)</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;If the scheduler.yield() proposal is extended to handle this, yield and return to me with high priority, does it just replace isInputPending() entirely?</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Maybe. &nbsp;There may be problems with throughput where you don&#39;t want to yield that frequently</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;My guess is we don&#39;t want to specify user will handle all user input before handling all micro tasks. &nbsp;Giving browsers flexibility to whatever they choose to do feels preferable.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Webkit does not have any mechanism to prioritize input</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Is input frame-aligned?</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Input is FIFO</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;We may not need a yield-only-to-input function</span></li><li class="c2"><span class="c3">... I think Tim&#39;s suggestion of expecting reasonable behavior and if not default to a timeout in the worst case or potential throttling</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Presumably isInputPending() signal may give you confidence to introduce a longtask where you would yield. &nbsp;But there could be other scripts that want to run. &nbsp;What about yielding to other script and making sure a bad actor can&#39;t take over the thread.</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;IIP is for script that already wants to do a longtask and has incentive for throughput wins, improve responsiveness and UX. &nbsp;Cooperative multi-tasking is out of scope for this...</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;Our team has discussed some options here, ..., we could lie in isInputPending if you&#39;re blocking the thread for too long and there are other things. &nbsp;Not sure if this is something we want to spec.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;isOkToBlock(), for future cases where it&#39;s not strictly related to input. &nbsp;In this case it&#39;s nice to scope it directly to the problem.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Regarding incubation status question, we had discussed it a few calls ago. &nbsp;One previous call it was favorable to consider for adoption, but a more recent call went the other way. &nbsp;Didn&#39;t want to make Rechartering dependent on incubations.</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h2 class="c16" id="h.wcme5s6epnp7"><span class="c10">Wednesday October 21</span></h2><h3 class="c8" id="h.8gfnc7p4nih"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://1drv.ms/p/s!Ajo0wos-4RKZjgw6pm1AldZ2V0iU?e%3DwaMbl1&amp;sa=D&amp;ust=1607595378348000&amp;usg=AOvVaw1dfxRHX9oo4CZs30RL2Ya7">Network Diagnostics API Proposal</a></span><span class="c24">&nbsp;- Noam Helfman</span></h3><ul class="c7 lst-kix_maqt99b0np5s-0 start"><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Not a spec or proposal, understanding a need for browser capability</span></li><li class="c2"><span class="c3">... Browser provides very limited network diagnostic information</span></li><li class="c2"><span class="c3">... May want to optimize UX based on network conditions</span></li><li class="c2"><span class="c3">... Key use case is local and last mile network conditions</span></li><li class="c2"><span class="c3">... Web app is required to determine state of local connection, enables app to notify user of local connectivity issues</span></li><li class="c2"><span class="c3">... App could suggest user move to a better reception area</span></li><li class="c2"><span class="c3">... App could adapt (payload size, call frequency)</span></li><li class="c2"><span class="c3">... Can collect this as RUM data</span></li><li class="c2"><span class="c3">... Existing solutions: NEL (no local network info, no client-side info)</span></li><li class="c2"><span class="c3">... Network Info API (too much or not enough sensitivity, not configurable)</span></li><li class="c2"><span class="c3">... Custom solution (via XHR calls, no local conn info)</span></li><li class="c2"><span class="c3">... Possible approaches. &nbsp;Approach 1: Network Info API. &nbsp;Extend current API to configure sensitivity thresholds (RTT to consider timeout, consecutive timeouts trigger notification)</span></li><li class="c2"><span class="c3">... Limitation is in flexibility, since different apps may have different needs (e.g. games requiring lower latency)</span></li><li class="c2"><span class="c3">... Approach 2: ping API. &nbsp;Attempt to diagnose local last mile connection -- pings default gateway</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;For Network Info API, the idea of custom thresholds is interesting. &nbsp;Current API exposes to many bits of entropy and doesn&#39;t give enough info in other cases.</span></li><li class="c2"><span class="c3">... Would love to have your active involvement on the repo -- current WICG only</span></li><li class="c2"><span class="c3">... Repo was not adopted as part of Devices and Sensors group</span></li><li class="c2"><span class="c3">... I think there&#39;s a path forward to modify the API to address concerns from other vendors</span></li><li class="c2"><span class="c3">... Could allow people to gather a small number of bits, but the bits they care about</span></li><li class="c2"><span class="c3">... For Ping API, knowledge of how far away I am from my router and providing that to random web pages seems risky</span></li><li class="c2"><span class="c3">... Would like to split out use cases where there&#39;s a need for local network information from general how is the network behaving</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Let&#39;s cover privacy aspects in later slide</span></li><li class="c2"><span class="c3">... [example]</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 344.00px;"><img alt="" src="images/image9.png" style="width: 624.00px; height: 344.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I think the API shape will be overshadowed by privacy issues</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Privacy concerns. &nbsp;Should user receive prompt to acknowledge and accept diagnosis. &nbsp;Apps already diagnose using hacks via XHR, image load timing, etc.</span></li><li class="c2"><span class="c3">... What is valid to report without violating privacy concerns</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Main difference I see here is you&#39;re pinging a specific local IP address that is not exposed</span></li><li class="c2"><span class="c3">... Today web content does not know what the local gateway is</span></li><li class="c2"><span class="c3">... Adding an explicit way to ping the default gateway could be a concern</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Another issue is exposing larger fingerprinting surface</span></li><li class="c2"><span class="c3">... UA should not report the default gateway IP address</span></li><li class="c2"><span class="c3">... Obfuscate ping results to mitigate fingerprinting</span></li><li class="c2"><span class="c3">... NetInfo API rounds to 25ms, could be more or less granular than that even</span></li><li class="c2"><span class="c1">Subrata:</span><span class="c3">&nbsp;How is it going to help in a VPN-connected network?</span></li><li class="c2"><span class="c3">... Second question is -- we already have a RTT, how does ping response time differ?</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Regarding VPN, that definitely changes routing table</span></li><li class="c2"><span class="c3">... More than 1 gateway can exist (default gateway would go to VPN IP)</span></li><li class="c2"><span class="c3">... Was going to consider diagnosing even more destinations, ping FQDN from site origin only</span></li><li class="c2"><span class="c3">... TCP ping to detect network congestion -- harder to define and do securely</span></li><li class="c2"><span class="c3">... Main concerns I&#39;m hearing are around privacy, is that correct?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Concern around privacy with new information being exposed. &nbsp;Maybe that could be put behind prompt?</span></li><li class="c2"><span class="c3">... I would like to understand the use-cases for this to be flushed out, versus NetInfo for local diagnostics</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Does anyone else here have a need for diagnostics of local network?</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Are the diagnostics here the responsibility of the web app, or more browser responsibility? &nbsp;More consistent, but gives the same user feedback.</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;If the app detect bad connectivity, it could adapt, change the payload or send data less frequently</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;But that could be covered by NetInfo API too, not necessarily local NetInfo</span></li><li class="c2"><span class="c3">... One note from Alex Russel in chat is that an async API that provides a prompt could be a good idea if this moves forward</span></li><li class="c2"><span class="c3">... Going back to NetInfo, wondering if other vendors have feedback on what a revamped API might be something they want to ship</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;We&#39;re all on-hands for QUIC, so this would be on backburner</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Would this be something you&#39;d eventually be willing to expose</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Maybe, but let&#39;s cut speculation short, we can&#39;t commit to this</span></li><li class="c2"><span class="c1">Sudeep:</span><span class="c3">&nbsp;I&#39;m Co-Chair of Web and Networks Interest Group</span></li><li class="c2"><span class="c3">... For NetInfo API, there are some proposals in 5G space with a lot of variations seen. &nbsp;Whether hints can be shared with apps, for doing buffering in advance, etc. &nbsp;Has dependencies on information from operator network, etc.</span></li><li class="c2"><span class="c3">... Second comment is orthogonal, there is an idea in our interest group where it&#39;s the other way around, to extend developer tools to extend time-variant conditions. &nbsp;There could be a network trace format where it&#39;s taken from the real-world and test how a web app behaves in network conditions, so the developer can adapt to network conditions.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Network trace idea sounds interesting in context of synthetic testing, but possibly orthogonal to this. If you could share links that&#39;d be great.</span></li></ul><h3 class="c5" id="h.61181ucixzu"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Ob63bm5iidx8-MvrIzdNLYcjLRvS4lvPAIYASURLSns/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378359000&amp;usg=AOvVaw2cAUpE6VQGHNn8gC3OXwC8">performance.measureMemory API update</a></span><span class="c24">&nbsp;- Ulan Degenbaev</span></h3><ul class="c7 lst-kix_cz3d376cg0uh-0 start"><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Why care about memory? &nbsp;Use more memory to improve performance</span></li><li class="c2"><span class="c3">... Use more memory due to memory leaks (slow growth over time, slowdown due to paging, garbage collection)</span></li><li class="c2"><span class="c3">&hellip; Hard to detect in local testing, which run for short times or as a result of specific actions</span></li><li class="c2"><span class="c3">&hellip; Main use case - how to measure memory usage in production</span></li><li class="c2"><span class="c3">... Useful for long running complex applications</span></li><li class="c2"><span>&hellip; Tradeoffs</span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 352.00px;"><img alt="" src="images/image17.png" style="width: 624.00px; height: 352.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span>API shape</span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 220.00px;"><img alt="" src="images/image8.png" style="width: 624.00px; height: 220.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">&hellip; Comparison to the non-standard API: current API is well defined, where the previous API may have leaked heap sizes from unrelated pages, based on implementation</span></li><li class="c2"><span class="c3">&hellip; Current API enables to break down the usage by owner (e.g. iframes) and type</span></li><li class="c2"><span class="c3">&hellip; Better security through cross origin isolation</span></li><li class="c2"><span class="c3">... An attacker can use the API to infer sizes of cross-origin resources, gate API behind self.crossOriginIsolated via COOP/COEP</span></li><li class="c2"><span>&hellip; Breakdown example</span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 329.33px;"><img alt="" src="images/image11.png" style="width: 624.00px; height: 329.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 282.67px;"><img alt="" src="images/image10.png" style="width: 624.00px; height: 282.67px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">&hellip; The browser could also group together attributions in cases that it cannot distinguish between them</span></li><li class="c2"><span class="c3">&hellip; We&rsquo;re ok to expose sizes of iframes but not ok with exposing URLs or strings</span></li><li class="c2"><span class="c3">&hellip; For same origin we can provide the most recent URL (post redirection), but for cross-origin we can only provide the pre-redirect URL</span></li><li class="c2"><span class="c3">&hellip; Origin trial is running in Chrome 85-87. Currently gated behind site-isolation, using simpler attribution format, can measure worker memory</span></li><li class="c2"><span class="c3">&hellip; Revamping to new attribution format, hoping to ship in Chrome 88</span></li><li class="c2"><span class="c3">&hellip; Got useful feedback from Mozilla, some concerns about interop that results in renaming to &ldquo;userAgentSpecific*&rdquo; to prevent confusion</span></li><li class="c2"><span class="c3">&hellip; Suggestion to add dummy entries to prevent users from relying on specific structures</span></li><li class="c2"><span class="c3">&hellip; Another open question - what should be the scope of API? Whole website or the parts that are in the current process?</span></li><li class="c2"><span class="c3">... Feedback from users - Promises take a long time to resolve - because the measurement happened as part of GC. Local testing can force measurement using a flag</span></li><li class="c2"><span class="c3">&hellip; Other feedback resulted in adding worker memory</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;What bytes are you reporting?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Sizes of objects allocated by that process</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;What&rsquo;s the reported size? In many OS you have a memory compressor, so the bytes in the physical sense may differ from the object size? Also dirty bytes from non-dirty bytes can differ. You can have a completely empty page that&rsquo;s dirty. </span></li><li class="c2"><span class="c3">&hellip; Also, how much of the memory is active?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;In Chrome we don&rsquo;t try to approximate the physical memory usage, but report the sizes as we allocate them. If the OS does something fancy, that wouldn&rsquo;t be captured.</span></li><li class="c2"><span class="c3">&hellip; Useful to avoid exposing system info due to fingerprinting concerns</span></li><li class="c2"><span class="c3">&hellip; To avoid fingerprinting, we should not surface memory that the webpage doesn&rsquo;t allocate</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;For example if you have a blob and map the contents of a blob</span></li><li class="c2"><span class="c3">&hellip; So the definition is implementation dependent, we could report anything</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Allocate a random buffer, should not be completely random</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;Need to agree what kind of bytes we&rsquo;re reporting</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Great work on this! CORS check is great progress. Can we make progress on the open issues?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;3 open issues about interop.</span></li><li class="c2"><span class="c3">&hellip; Scope somehow related to security, smaller scope would provide better security, but results may vary more per device</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;In terms of attribution, does the API distinguish between JS, images, GPU, etc?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Currently only JS memory, but plans to add DOM and GPU memory</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;Would the GPU memory expose the total available GPU memory? In contrast to RAM, where the OS uses paging, full GPU memory can cause bad things. Would be good to get full GPU memory.</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;We could maybe approximate it. Limits of GPU memory is out of scope, different privacy and security review</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;In practice it&rsquo;s already exposed by allocating canvases</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;Have there been any success stories of real regressions found using this?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Origin trial has been running for a while but with the old scope, latest changes not available yet, maybe in a month or so</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;Such a story could make this more compelling</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Questions about scope?</span></li><li class="c2"><span class="c1">Domenic:</span><span class="c3">&nbsp;Found arguments compelling</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;Concerned about exposing memory from cross origin iframes</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;To emphasise, this is only for pages that are cross-origin isolated</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;Concern still stands about exposing memory information for cross-origin iframes</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;For information leak?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;It won&rsquo;t be observable if they are in the same process or not</span></li><li class="c2"><span class="c1">Rniwa:</span><span class="c3">&nbsp;Have to read the proposal</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c8" id="h.frj07uevyuvj"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1l8LH7OSjnzUnBcIkBzUhQpV49RmeTNszLsiqrlWAmhs/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378370000&amp;usg=AOvVaw0FEpEIagaSmLW9efbTkvVg">Rechartering, Call for Editors</a></span><span class="c24">&nbsp;- Yoav, Nic</span></h3><ul class="c7 lst-kix_wpf36ljeh9si-0 start"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We were scheduled to be rechartered back in June, extended old charter to accommodate Process 2020 to Dec 31 2020</span></li><li class="c2"><span class="c3">... Desire to move to Living Standards, and CR draft model</span></li><li class="c2"><span class="c3">... Get to CR and update the CR once in a while as needed</span></li><li class="c2"><span>... </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit%23heading%3Dh.giqsyxufsysg&amp;sa=D&amp;ust=1607595378371000&amp;usg=AOvVaw3KzHKYGuyOiqGyIPs926PW">Draft charter</a></span></li><li class="c2"><span class="c3">... Doesn&#39;t change much around deliverables</span></li><li class="c2"><span class="c3">... Changes to scope around making it more explicit, previous was vague around somehow improving the user experience</span></li><li class="c2"><span class="c3">... Splitting categories of improvement into measurement, scheduling and adaptations</span></li><li class="c2"><span class="c3">... This covers all deliverables we have today as well as what we had in the past</span></li><li class="c2"><span class="c3">... Can we publish pre-rechartering? &nbsp;ResourceTiming L1, PageVisibility L2 to REC</span></li><li class="c2"><span class="c3">... Post-rechartering, Beacon to PR and requestIdleCallback to REC</span></li><li class="c2"><span class="c3">... Should we remove preload and resource-hints as deliverables</span></li><li class="c2"><span class="c3">... Moving resource hints directly into HTML</span></li><li class="c2"><span class="c3">... Unclear if we remove them entirely, or state that they&#39;re deliverables in transition</span></li><li class="c2"><span class="c3">... For everything else, get to CR, make changes to CR-draft, iterate</span></li><li class="c2"><span class="c3">... We have some specs that could use adoption for editors: Server Timing, Long Tasks, requestIdleCallback, ResourceTiming+NavTiming rewrite</span></li><li class="c2"><span class="c3">... Level of effort varies based on the spec. &nbsp;Even if you have a few hours a week that you could dedicate to the subject it would be appreciated and could use your help.</span></li><li class="c2"><span class="c3">... Make sure issues don&#39;t lag</span></li><li class="c2"><span class="c3">... We can help you get started and be successful</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;First question was about going to REC before the beginning of the year, for RTL1 and PVL2</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;RTL1 is complete and PVL2 has one open issue that we could resolve rather quickly</span></li><li class="c2"><span class="c3">... Otherwise we can leave it as a deliverable and aim to get it next quarter</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;We can&#39;t remove them from the charter because the working group needs to maintain them</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We plan to keep maintaining them. &nbsp;RTL1 would be done, but RTL2 will not be. &nbsp;We have both in the charter. &nbsp;Committed to keeping RTL2 as a living standard.</span></li><li class="c2"><span class="c3">... PageVisibility we think would be similar, L3 ongoing as a living standard</span></li><li class="c2"><span class="c3">... Clean up the fact that we have two different levels as a deliverable</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;We have 2.5 months, it will be tricky but possible</span></li><li class="c2"><span class="c3">... For RTL1, are there modifications, do we need a new CR?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I don&#39;t think so, we just forgot to move it to REC</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Yes, we should be able to do that by EOY</span></li><li class="c2"><span class="c3">... For PageVis, do you want it as a Living Standard?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Ideally we could have L2 go to REC, then L3 be a living standard for anything we add in the future</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Do you anticipate L3 would be highly different than L2</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Potentially we would be interested in adding more mods or signals (RE: prerender)</span></li><li class="c2"><span class="c3">... There will be an API change</span></li><li class="c2"><span class="c3">... Do you prefer we just take L2 to be living standard?</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;That&#39;s a possibility, not necessarily the right thing to do, depends on the approach for versioning</span></li><li class="c2"><span class="c3">... We use levels for the moment, but we didn&#39;t have living standard before</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Either way we want it to be more backwards compatible</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Thanks for this discussion, I wanted more clarity about the living standards part.</span></li><li class="c2"><span class="c3">... More clarification about how this evolves. &nbsp;Does that mean we can&#39;t remove interfaces?</span></li><li class="c2"><span class="c3">... Can we just call it Page Visibility 2020?</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Difference between going to REC the old way and now as Living Standard</span></li><li class="c2"><span class="c3">... When you enter PR, you have to say it&#39;s going to become a Living Standard</span></li><li class="c2"><span class="c3">... When you&#39;re in PR as that, you go through a different process. &nbsp;Which combines patent protection done at CR and the AC vote at PR.</span></li><li class="c2"><span class="c3">... The other change is the CR draft and snapshot are distinguished</span></li><li class="c2"><span class="c3">... Where before some CRs were editorial and some were substantial</span></li><li class="c2"><span class="c3">... The only thing about living standard is about amending and changing the recommendation in place</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;And where is the point of comments to indicate a change in living standard</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;There&#39;s something in the process called &quot;last call for review&quot;</span></li><li class="c2"><span class="c3">... And that will be a CR/PR mix of review</span></li><li class="c2"><span class="c3">... Normally that should lead to recommendation that will result in a new spec with additional content</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;In previous discussion we concluded, the Living Standard variant of amended REC would be something that has relatively high overhead, so we&#39;d prefer the CR-draft version. &nbsp;Draft snapshots will be the tip-of-tree.</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Yes, previously if you wanted to add a feature to a REC, adding an API to something that already exists, you had to go to PWD, an entire new track. &nbsp;Now if you&#39;re marked as Living Standard, you can incorporate that and directly go to CR. &nbsp;CR are snapshots with patent policy protection.</span></li><li class="c2"><span class="c3">... You don&#39;t really need to go to REC again, unless your spec is relatively mature</span></li><li class="c2"><span class="c3">... You don&#39;t have levels, but when you think your L2 is done you publish as REC then work to L3 as CR directly without going to PWD</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I think that piece we&#39;ll have to think about closer to an existing example</span></li><li class="c2"><span class="c3">... Maybe we can try that out with PageVis, move it to REC as living standard, then move it back to CR to add prerendering bits</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;That does not prevent publishing L3 as WD</span></li><li class="c2"><span class="c3">Michael Smith: One thing I wanted to talk about was something Benjamin asked specifically</span></li><li class="c2"><span class="c3">... Worked for W3C on a lot of transitions</span></li><li class="c2"><span class="c3">... Benjamin asked is it considered a breaking change if you remove an API</span></li><li class="c2"><span class="c3">... The general answer we have is that if any change will invalidate someone&#39;s previous review, then you should give your reviewers an opportunity for review</span></li><li class="c2"><span class="c3">... Think about if you reviewed someone else&#39;s spec, if you find out after the fact they made a change afterward and went ahead that invalidated the previous review they did, that wouldn&#39;t be considerate</span></li><li class="c2"><span class="c3">... Just think about if they&#39;d want an opportunity to re-review</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;How does disposition of comments work then</span></li><li class="c2"><span class="c3">... From TAG review, that seemed ad-hoc</span></li><li class="c2"><span class="c3">... I want to make sure there&#39;s a place where these re-reviews can happen</span></li><li class="c2"><span class="c3">... I just want to make sure we track these reviews and comments</span></li><li class="c2"><span class="c3">... So people in other WGs can see what we&#39;re up to</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Do you have an example of other specs that follow that?</span></li><li class="c2"><span class="c1">Benjamin:</span><span>&nbsp;I do have an example, I&#39;ll follow up and provide one</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;That sounds generally useful</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;That would track things in a changelog in the doc</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;The other question was about removing preload/resource hints as deliverables, or can we add them as a separate section about deliverables-in-transition, for things that are in-flight between W3C and WICG</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;If we don&#39;t plan on delivering them from this group, it should be removed from deliverables in this section</span></li><li class="c2"><span class="c3">... For AC review of this charter, it would be nice for them to know what is happening for these specs</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Is there a section non-normative text</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;We don&#39;t have a section, but more as a freestyle section of the charter</span></li><li class="c2"><span class="c3">... Either under &quot;other deliverables&quot; or &quot;liaison to other groups&quot;</span></li><li class="c2"><span class="c1">Michael:</span><span class="c3">&nbsp;To clarify, is the content of those specs being integrated into HTML Spec?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Yes</span></li><li class="c2"><span class="c1">Michael:</span><span class="c3">&nbsp;I would say when that does happen, along with whatever else you do, please make sure we know what&#39;s going on, especially relationship with WHATWG where we coordinate</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Yep, Philippe is aware</span></li><li class="c2"><span class="c3">... Review the draft, and add comments there</span></li><li class="c2"><span class="c3">... We&#39;ll kick off rechartering soon</span></li></ul><h3 class="c5" id="h.ft9c84pgmoe5"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1sslnZi2MYyKlNb6LoS_vTlcvshkUR0IUekacq4mZMhs/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378387000&amp;usg=AOvVaw3C_AqdD2TquBt_v_VWre8d">Long Tasks attribution</a></span><span class="c24">&nbsp;- Patrick Hulce</span></h3><ul class="c7 lst-kix_lefaqjc90zys-0 start"><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Working on Lighthouse. Not a formal proposal, but want to describe how Lighthouse tackled this problem and if we can apply it here</span></li><li class="c2"><span class="c3">&hellip; Lighthouse is a lab tool that captures performance metrics. Identifying the cause of main thread work is really critical for us.</span></li><li class="c2"><span class="c3">&hellip; Knowing that a lot of work happened is not useful on its own. People want to know why!</span></li><li class="c2"><span class="c3">&hellip; Developers need to know who&rsquo;s responsible for every single long task</span></li><li class="c2"><span class="c3">&hellip; We want to find an &ldquo;proximate cause&rdquo; for work. Which is different from why is the long task actually long. (which is the current focus of &ldquo;attribution&rdquo; in the LT spec)</span></li><li class="c2"><span class="c3">&hellip; Want to walk through motivating examples</span></li><li class="c2"><span class="c3">&hellip; Terms</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-1 start"><li class="c9 c15"><span class="c3">EvaludateScript - initial script execution</span></li><li class="c9 c15"><span class="c3">Self-time - time spent executing while source is at the top of the stack</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-0"><li class="c2"><span class="c3">Examples</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-1 start"><li class="c9 c15"><span class="c3">Badscript.js causing browser layout thrashing</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-2 start"><li class="c9 c13"><span class="c3">Self time is not good here</span></li><li class="c9 c13"><span class="c3">It caused a lot of layout work</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-1"><li class="c9 c15"><span class="c3">EvaluateScript with a library</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-2 start"><li class="c9 c13"><span class="c3">Most time spent in jQuery, but badscript.js is calling jquery and is the cause</span></li><li class="c9 c13"><span class="c3">Maybe we want to top of the stack</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-1"><li class="c9 c15"><span class="c3">setTimeout with a library</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-2 start"><li class="c9 c13"><span class="c3">No stack!!</span></li><li class="c9 c13"><span class="c3">Need to find the script that scheduled the setTimeout</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-1"><li class="c9 c15"><span class="c3">Chained Script</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-2 start"><li class="c9 c13"><span class="c3">What if another script adds badscript.js? </span></li><li class="c9 c13"><span class="c3">In lighthouse we stop at a script with a url, so in this case badscript.js is the cause, not the script that inserted it</span></li></ul><ul class="c7 lst-kix_lefaqjc90zys-0"><li class="c2"><span class="c3">&hellip; Observation - attribution should take causality to the extreme, the &quot;document&quot; could be the cause of all the long tasks</span></li><li class="c2"><span class="c3">... Taken not far enough, and the &quot;browser engine&quot; is the cause of all.</span></li><li class="c2"><span class="c3">&hellip; In Lighthouse, cross-origin leaks are not really a concern, and have access to a profiler</span></li><li class="c2"><span>&hellip; They attribute long tasks by walking back to tasks that eventually triggered tasks</span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 328.00px;"><img alt="" src="images/image5.png" style="width: 624.00px; height: 328.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">&hellip; Works fine for setTimeout and XHR, less so for fetch() and event listeners, due to implementation deficiencies, but cannot provide attribution for DOM mutations or non-JS async work</span></li><li class="c2"><span class="c3">&hellip; 99.6% of LTs get attribution, 96% have all LTs attributed</span></li><li class="c2"><span class="c3">&hellip; Been using it for 2 years, and it seems to meet developer expectations</span></li><li class="c2"><span class="c3">&hellip; That method of attribution doesn&rsquo;t over-attribute work to polyfills and monkey-patches</span></li><li class="c2"><span class="c3">&hellip; But, scheduler scripts see inflated attribution if work is pushed through a queue, which is not tracked</span></li><li class="c2"><span class="c3">&hellip; Also, don&rsquo;t know how it would work for post-interaction work, as LightHouse doesn&rsquo;t do that</span></li><li class="c2"><span class="c3">&hellip; Open questions: Is the model of proximate cause for attribution widely applicable to other things?</span></li><li class="c2"><span class="c3">... Could this be implemented cross-browser?</span></li><li class="c2"><span class="c3">... Would this model yield developer value for other APIs like Long Tasks or measureMemory after cross-origin concerns are taken into consideration?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Wondering whether the pieces where we cannot attribute are fundamental, or just implementation driven. &nbsp;In particular, scheduler scripts and work being pushed from a queue. &nbsp;Can that work be attributed to avoid over-blaming scheduler scripts.</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;I think the scheduler problem needs to be solved at least partially via some sort of developer annotation. &nbsp;It needs to say it&#39;s work from one context or another.</span></li><li class="c2"><span class="c3">... Automatic attribution, even if it were heuristic based, might be lower quality</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;Talked to V8 team about tracking each variable and what&#39;s mutating it, and their feedback was it was expensive</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;How much do you need stack sampling here?</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Standard auditing isn&#39;t enabled by default for traces, so it&#39;s just a bonus to narrow down what&#39;s happening. &nbsp;All annotation here is micro-tasks relationships.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Regarding last question and cross-origin concerns, if we limit information which is just the pre-redirect URL, which is already information the page has or can obtain, a page could stagger the loading of different scripts to figure out which script is triggering a long task. &nbsp;Seems like something people can do today, regardless of the LT API, just setTimeout timing attacks.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;We already talked about your talk for interactions/responsiveness. It&rsquo;s possible that EvaluateScript is happening in cases like click handlers, etc, rather than attributing longtasks back</span></li><li class="c2"><span class="c3">&hellip; Any future async work that&rsquo;s in the chain could be attributed to the initial work</span></li><li class="c2"><span class="c3">&hellip; So we could use this for responsiveness</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Almost like taking the extreme example that it came from the document</span></li><li class="c2"><span class="c3">&hellip; The correct information can be useful for other scenarios, excited to see how you&rsquo;d use it.</span></li><li class="c2"><span class="c3">&hellip; Also, opinions from RUM providers?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;For Akamai mPulse, we&rsquo;re capturing LTs in the world, but have no attribution. Customers always ask what they can do with it. More things we can track from RUM to point fingers can save time and help customers find culprits in the wild. Any more information on LTs would make the data way more useful. Right now can&rsquo;t say more than &ldquo;this happened&rdquo;. So attributions is a major request for us.</span></li><li class="c2"><span class="c3">&hellip; Also, what 3P are doing on the page can help folks from stopping to point fingers on the mPulse script as the culprit as we wrap top-level APIs</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;Another useful need for that attribution could be in the case of exception and stack traces. Would be useful that have traces go beyond async handler, what script added the handler</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Mentioned cross-browser implementation feasibility. Did you investigate?</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;I suspect it could be, but would love to hear from browser vendors. Task coalescing can be different</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Other browser vendors, any hunches regarding feasibility?</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;Sounds difficult and potentially expensive to implement, but no fundamental problems. Those are big hurdles.</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;We&#39;re behind on Long Tasks, so I choose not to speculate here.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Regarding cross-origin concern, we can follow up with security folks</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;What would be a reasonable next step?</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;Can you file an issue on the LT repo to show the use cases you&rsquo;re addressing?</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;SG</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;As Alex mentioned it&rsquo;s not cheap for us to implement, so want clear answers to cross-origin concerns. Having more data to gain confidence would encourage us to say it&rsquo;s worth further investment</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;Cost is unclear to me as well. Ulan - who can we ask?</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;&lt;name dropping&gt;</span></li><li class="c2"><span class="c1">Tim:</span><span class="c3">&nbsp;Also talk to Scott on Scheduling</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Given that every macrotask already attributes its source?</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;With tracing enabled</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Need to check if the data that goes into the trace is available</span></li><li class="c2"><span class="c1">Npm:</span><span class="c3">&nbsp;Yeah, need to investigate</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.kfbl5bobg2q9"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1WcSza4A74y5kiuF1xNUCTKjcgTaoQBHl01FGPCGSxVo/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378401000&amp;usg=AOvVaw0EAr5S-Oy2KMh3F9ysCljy">JS self-profiling update</a></span><span class="c24">&nbsp;- Andrew Comminos</span></h3><ul class="c7 lst-kix_hz8i7r30ijjn-0 start"><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;API to sample client-side JavaScript</span></li><li class="c2"><span class="c3">... Just like DevTools</span></li><li class="c2"><span class="c3">... Chrome OT M78-80</span></li><li class="c2"><span class="c3">... API changed to now require COOP/COEP</span></li><li class="c2"><span class="c3">... Can contain stack frames from X-O resources</span></li><li class="c2"><span class="c3">... [example trace]</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 346.67px;"><img alt="" src="images/image14.png" style="width: 624.00px; height: 346.67px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span>... Github repo: </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://meet.google.com/linkredirect?authuser%3D0%26dest%3Dhttps%253A%252F%252Fgithub.com%252FWICG%252Fjs-self-profiling&amp;sa=D&amp;ust=1607595378403000&amp;usg=AOvVaw2_Sk_OlaqX6G4cD7MPCsDw">https://meet.google.com/linkredirect?authuser=0&amp;dest=https%3A%2F%2Fgithub.com%2FWICG%2Fjs-self-profiling</a></span></li><li class="c2"><span class="c3">... Origin Trial feedback: Found and resolved a ton of performance issues at Facebook</span></li><li class="c2"><span class="c3">... Commonly useful for interactions</span></li><li class="c2"><span>... Testimonials in </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://meet.google.com/linkredirect?authuser%3D0%26dest%3Dhttps%253A%252F%252Fgithub.com%252FWICG%252Fjs-self-profiling&amp;sa=D&amp;ust=1607595378405000&amp;usg=AOvVaw3a43izETkRsWUf-IlpV1vt">Github</a></span><span>: </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/WICG/js-self-profiling/issues/21&amp;sa=D&amp;ust=1607595378405000&amp;usg=AOvVaw2f92wDiZ3oEROGxnbP8MJi">https://github.com/WICG/js-self-profiling/issues/21</a></span><span>, </span><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://github.com/WICG/js-self-profiling/issues/24&amp;sa=D&amp;ust=1607595378405000&amp;usg=AOvVaw22-gOhsmvzxpIHj9YayeY6">https://github.com/WICG/js-self-profiling/issues/24</a></span><span class="c3">&nbsp;</span></li><li class="c2"><span class="c3">... Highlighted need for API to be very performant</span></li><li class="c2"><span class="c3">... Activation: Profiling requires work and we need to figure out when to do it</span></li><li class="c2"><span class="c3">... Wanted to use Feature/Permissions Policy, but lack of support in workers and no &ldquo;disabled by default&rdquo; option shut that down</span></li><li class="c2"><span class="c3">... Options: </span></li></ul><ul class="c7 lst-kix_hz8i7r30ijjn-1 start"><li class="c9 c15"><span class="c3">Script-driven warm up? Would need to be done on the main thread. &nbsp;A lot cheaper to do this online than stopping the world and re-doing.</span></li><li class="c9 c15"><span class="c3">Amend Permission Policy. &nbsp;Needs to support disabled-by-default params, worker propagation</span></li><li class="c9 c15"><span class="c3">Add a new header</span></li></ul><ul class="c7 lst-kix_hz8i7r30ijjn-0"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;What are the blockers for Permissions Policy?</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;disabled-by-default use-case is fine, but shared worker issues could open up dialog</span></li><li class="c2"><span class="c1">Yoav:</span><span>&nbsp;Take AI to start dialog</span><sup><a href="#cmnt1" id="cmnt_ref1">[a]</a></sup></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;We can take that offline then for now</span></li><li class="c2"><span class="c3">... Also want to solve the hardest problem in computer science</span></li><li class="c2"><span class="c3">... Naming is hard</span></li><li class="c2"><span class="c3">... No other spec uses the label &quot;JS&quot;</span></li><li class="c2"><span class="c3">... What is &quot;self-profiling&quot; anyways?</span></li><li class="c2"><span class="c3">... &quot;JavaScript Sampling API&quot; proposed</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Would like to think about what someone outside of this context would think of the name. &nbsp;Profiling sees bad.</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;To answer Carnine&#39;s question &quot;sampling does not mean anything precise to me&quot;, &quot;sampling&quot; in isolation maybe doesn&#39;t mean anything, JavaScript Sampling itself is pretty unambiguous to what it refers to</span></li><li class="c2"><span class="c3">Michael Smith: The word &quot;Self&quot; isn&#39;t in any other of these candidates</span></li><li class="c2"><span class="c3">... Because it&#39;s fundamental to the whole feature, the application has APIs to measure its own performance</span></li><li class="c2"><span class="c3">... Don&#39;t have a strong opinion</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;The &quot;What is self profiling anyways&quot; comment resonated with me</span></li><li class="c2"><span class="c3">(some other naming suggestions in chat)</span></li><li class="c2"><span class="c3">Paul Irish: Does the API differentiate between idle time and spent in recalc style/layout</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;It&#39;s just script for now</span></li><li class="c2"><span class="c1">Paul:</span><span class="c3">&nbsp;In the spec right now there is a Profiler Trace dictionary, may want to change the name of that interface</span></li><li class="c2"><span class="c3">... Anyone who engages with the API can see the result is samples</span></li><li class="c2"><span class="c3">... Priority would be communicating it&#39;s just JavaScript (and not layout, idle, everything else)</span></li><li class="c2"><span class="c1">Boris:</span><span>&nbsp;</span><span>It really depends on whether you want to limit the potential of the API. If in the future it also allows to view layout profiling, Performance Profile API sounds better.</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;In the future we may want to have potential of other things to sample</span></li><li class="c2"><span class="c3">... I like the idea of Performance Profiler API</span></li><li class="c2"><span class="c3">... TAG review has finished</span></li><li class="c2"><span class="c3">... Would like to see comments in Origin Trials survey</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I was confused by &quot;self&quot; in the name as well, is it there&#39;s a special &quot;self&quot; time or that a web developer can trigger it via an API</span></li><li class="c2"><span class="c3">Michael Smith: Encouraged by the API itself, how it can be useful for developers, but concerned Apple would not be willing to implement it at all.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Our position has not changed</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Is the concern around smaller sites?</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;API could incur too much runtime costs</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Cost for startup, or runtime?</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;This is not something we will implement, we will strongly object</span></li><li class="c2"><span class="c1">Michael:</span><span class="c3">&nbsp;I trust your sense of the cost of this, are you confident the cost is so much it&#39;s a non-starter.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;We&#39;re talking about something that could be a cost of 10%+ and a power cost. &nbsp;We&#39;re not adding a feature that drains a user&#39;s battery.</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;You can get a lot of signal from a small percentage of users, and from that small sample you can fix major performance problems.</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;I understand that and disagree with that proposition</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;There are some websites with smaller users than Facebook</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;In which case they would not need this API</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Or they enable it once and forget about it</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;There are a lot of APIs that are footguns</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;The COEP requirement in the short-run is going to be a hurdle for any site that incorporates third-parties or X-O resources</span></li><li class="c2"><span class="c3">... If the concern is around developers setting and forgetting it, we could incorporate sampling into the API itself.</span></li><li class="c2"><span class="c3">... As a developer it could say I want it on N% of visitors or users</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;We don&#39;t want to encourage A/B sampling behavior</span></li><li class="c2"><span class="c1">Patrick:</span><span class="c3">&nbsp;I don&#39;t know if this is the case for Webkit, there&#39;s probably a non-zero cost to having that code in there at all, versus having the code in the engine</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;We managed to mitigate a lot of this because we legeraged the sampling profiler already built in</span></li><li class="c2"><span class="c1">Michael:</span><span class="c3">&nbsp;There are a number of sites that are on roughly the same scale that could benefit from this. &nbsp;If we&#39;re trying to fix experiences for users of the web, similar websites from other companies can help for a massive number of users.</span></li><li class="c2"><span class="c3">... It would be nice to see if there&#39;s a way we can get this implemented for the web platform</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Our approach to perf is not to let websites optimize for our engine, it&#39;s for our engine to optimize for content out there.</span></li><li class="c2"><span class="c3">... We just don&#39;t do this type of A/B testing in general in our products</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;A/B could be otherwise considered we are granting the website this much resource or signal to gather this data</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Which is what we don&#39;t want to do</span></li><li class="c2"><span class="c1">Andrew:</span><span class="c3">&nbsp;Just speaking from a product POV we&#39;ve found this to be massively useful</span></li><li class="c2"><span class="c1">Gilles:</span><span class="c3">&nbsp;It would be useful for us at Wikipedia since we&#39;re seeing such variations in JS users are running, we even let users running their on JS on the site. &nbsp;So depending on what article or user, the difference can be significant.</span></li><li class="c2"><span class="c3">... This would allow us to sample random pages and look at patterns</span></li><li class="c2"><span class="c3">... I think for any website that has different users getting different experiences, at scale, this could be useful</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Wikipedia is another good example where they can abide by COEP COOP restrictions due to a lack of third-parties</span></li><li class="c2"><span class="c3">... With that, we&#39;re out of time, see everyone tomorrow!</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h2 class="c16" id="h.tf1o2us0vlc9"><span class="c10">Thursday October 22</span></h2><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.cc3elzozxjup"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1J98XeN6gwETrbO0soqQeg2kpxqoDkVRy7q3SzxrJLhM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378419000&amp;usg=AOvVaw0qcF9rGWlTGxtf4yZK5YIb">TAO and CORS/CORP opt-ins</a></span><span class="c24">&nbsp;- Yoav</span></h3><ul class="c7 lst-kix_knxgn3f8infz-0 start"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;We have a lot of opt-ins</span></li><li class="c2"><span class="c3">... They&#39;re not well layered, and developers may need to set all of them</span></li><li class="c2"><span class="c3">... Timing-Allow-Oigin, Cross-Origin-Resource-Policy and Cross-Origin-Resource-Sharing</span></li><li class="c2"><span class="c3">... Information types: For resources, we have resource-level timing, origin-level timing and user-network-level timing</span></li><li class="c2"><span class="c3">... Resource sizes</span></li><li class="c2"><span class="c3">... Caching information (via transferSize)</span></li><li class="c2"><span class="c3">... In the future, we have feature requests for new info, like HTTP status codes or content type</span></li><li class="c2"><span class="c3">... Plus reporting of frame timings to its parent</span></li><li class="c2"><span class="c3">... Proposal: Timings: Provided by TAO, could also be provided if CORS, may need a separate host-level opt-in</span></li><li class="c2"><span class="c3">... Sizes information: Don&#39;t want to allow for TAO enabled resources, but do want to allow for CORP and CORS</span></li><li class="c2"><span class="c3">... Information already provided via CORP and memory APIs</span></li><li class="c2"><span class="c3">... Caching: Expose via CORP</span></li><li class="c2"><span class="c3">... Metadata such as status code and content type: CORP maybe</span></li><li class="c2"><span class="c3">... Parent frame reporting - something else entirely</span></li><li class="c2"><span class="c3">... nextHopProtocol is behind TAO, but that doesn&#39;t make sense because it&#39;s information already observable and exposes information about the user&#39;s network (e.g. proxy downgrade)</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;How is it observable?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;If you trigger more than 6 requests and look at the network characteristics</span></li><li class="c2"><span class="c3">... e.g. HTTP/1 vs. HTTP/2 characteristics are different from another</span></li><li class="c2"><span class="c3">... HTTP/3 vs. HTTP/2 may be more complex</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;For clarification, are you saying if CORS, then you&#39;d have access to timing, sizes, caching, metadata.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Correct</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;So CORS becomes a mode where you say that the resource becomes similar to a same-origin resource for the specified origin. </span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;In a way. Since CORS provides byte-for-byte access to these resources</span></li><li class="c2"><span class="c3">... All of this information could be polyfilled without ResourceTiming</span></li><li class="c2"><span class="c3">&hellip; Calling it same-origin may confuse people regarding the credentials handling</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;In terms of information about the resource it would behave similarly to a same-origin resource</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;I&#39;m skeptical that because CORS allows resource to be read, that all these things are observable</span></li><li class="c2"><span class="c3">... Things like size for some types aren&#39;t observable</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Let&#39;s talk about timings first maybe</span></li><li class="c2"><span class="c3">... responseStart and all those points in-between, related to resource-level loading</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Opt-ins for CORS never agreed to that timing information</span></li><li class="c2"><span class="c3">... CORS has existed for decades, and it&#39;s problematic to say this thing now provides a new thing. &nbsp;Bad to have an existing feature do more stuff and make it less secure.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;My claim is it&#39;s not less secure because it&#39;s already exposing all those things, and you can see when each byte has hit the client</span></li><li class="c2"><span class="c1">Artur:</span><span class="c3">&nbsp;Could you talk about the delta between what&#39;s exposed right now and the difference between CORS</span></li><li class="c2"><span class="c3">... If we see everything behind TAO is also observable via CORS</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Looking at ResourceTiming and points in time it enables</span></li><li class="c2"><span class="c3">... redirectStart/end, domainLookupStart/end, connectStart/End, secureConnectionStart, requestStart, responseStart, responseEnd</span></li><li class="c2"><span class="c3">... Without TAO all we have is startTime, fetchStart and responseEnd</span></li><li class="c2"><span class="c3">... TAO gives us opt-in to everything in-between</span></li><li class="c2"><span class="c3">... If we&#39;re talking about what does CORS enable us to observe, I believe it will enable us to observe responseStart, </span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;I think it&#39;s problematic to expose how much TLS or DNS took</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;Seems to me as well it&#39;d be hard to see how CORS would enable that</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;There&#39;s information about what the server is doing, versus how the network responds. &nbsp;CORS wouldn&#39;t give worker, app cache, DNS, TCP.</span></li><li class="c2"><span class="c3">... Network considerations that seem different from server considerations</span></li><li class="c2"><span class="c3">... CORS lets you get access to all the bytes</span></li><li class="c2"><span class="c3">... Not necessarily to how to get all that information to you</span></li><li class="c2"><span class="c3">... Doesn&#39;t seem CORS gives you any more work to have access to network conditions than how TAO does</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;One more question: if TAO only gives you timings, that seems like a simple enough mental model vs. having implication on parts of TAO that seem much more complicated</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;the motivation is that we have low adoption of TAO even for static, public resources, and introducing CORS into the equation would significantly increase our visibility to what 3Ps are doing, without compromising security</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Agree for things that the server has control over, but disagree on things where the server is just an end point.</span></li><li class="c2"><span class="c3">&hellip; Characteristics of how bits come to you, that&#39;s CORS</span></li><li class="c2"><span class="c3">... Different than DNS, which has nothing to do how long the resource took</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Agreed those are different types of information (resource-leve, origin-level, user-network level)</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Concerned more about network level characteristics than origin-level</span></li><li class="c2"><span class="c3">... The DNS-level data seems different nor that CORS would let you see that data</span></li><li class="c2"><span class="c3">... I think that&#39;s also true of nextHopProtocol</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Yep</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;If we&#39;re thinking about this for opt-ins, and if you have TAO, and without it, you don&#39;t have timings. &nbsp;If I want timings, I have TAO.</span></li><li class="c2"><span class="c3">... versus the implications if you have CORS that you get parts of timing</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Motivation after many years we still have low adoption of TAO</span></li><li class="c2"><span class="c3">... Even if we have static resources that are not sensitive and no one cares about timing</span></li><li class="c2"><span class="c3">... Having information to these shared public resources would give better insight into third-party visibility</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;I agree for things the server has control over (resource-level), origin-level we could talk about, user-network level I don&#39;t see the justification for that</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Moving to sizes, sizes are exposed with TAO, and what I&#39;m proposing is that we would stop, and would enable browsers that haven&#39;t implemented sizes would be able to.</span></li><li class="c2"><span class="c3">... We would move away from a TAO opt-in to a CORP opt-in. &nbsp;Not sure if on its own it would give you the size for any random attacker</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;The reason CORP is used for cross-origin isolation and not CORS, is we wanted to create a distinction between reading all the bits and content, versus the ability to use that on your website.</span></li><li class="c2"><span class="c3">... Ability to include on your page, but not understand what it is</span></li><li class="c2"><span class="c3">... So both sizes and metadata concern me with access-leaks repository. &nbsp;They use things like size and timings and metadata, and distinctions between failed request and successful request, side-effects from 500 and 404 error, for determining a particular resource was for a logged in user and not logged in, or what a particular user has access to.</span></li><li class="c2"><span class="c3">... So I&#39;m a little worried about blurring the line between reading a resource and including a resource</span></li><li class="c2"><span class="c3">... Then CORP can&#39;t give you size, and CORP can&#39;t give you metadata. &nbsp;It can only give you access to pull in a resource. &nbsp;For size in particular we may already be over that line with measureMemory() work.</span></li><li class="c2"><span class="c3">... Wondering if that framing makes any sense</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Reason I thought it&#39;s OK was because of memory measurement, already exposing those sizes.</span></li><li class="c2"><span class="c3">... JS profiling goes beyond embeddability of the resource and enables profiling of JS resources</span></li><li class="c2"><span class="c3">... Doesn&#39;t give byte-by-byte, but gives characteristics</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;My understanding was only related to the size of the JavaScript, does it include other things like images and fonts</span></li><li class="c2"><span class="c1">Ulan:</span><span class="c3">&nbsp;Initially it was about JavaScript, but after cross-origin isolation we thought we could expand it to more memory</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;None of that gives you metadata though</span></li><li class="c2"><span class="c1">Artur:</span><span class="c3">&nbsp;I think the answer to what Mike mentioned. &nbsp;One is explicitly APIs like measureMemory() and by setting CORP you&#39;re allowing it to be loaded into address space of cross-origin renderer. &nbsp;In practice it allows you to put resource into render, so it can read the specific bytes, size of resource, and the metadata in that resource.</span></li><li class="c2"><span class="c3">... So if you&#39;re a website that allows your resource to opt-in in a way that allows this, it&#39;s hard to make a argument that it&#39;s unsafe to expose that information</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;The way I was thinking about this a year ago, is to make the attacker to do the attack. &nbsp;There is risk a malicious entity could gain information. &nbsp;CORS grants that access, an explicit mechanism to give access. &nbsp;There&#39;s a meaningful difference in intent between a server that wants its resources to be included versus a resource that&#39;s going to be read.</span></li><li class="c2"><span class="c3">... We know that&#39;s not the case today, like Spectre attacks and other side-channels reveal this info, but we don&#39;t need to bake that into the APIs.</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;But in that case, why do we say it&rsquo;s ok to be cross-origin isolated and not require that all subresources in those contexts go through CORS rather than CORP</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;I think that&#39;s the conclusion you would reach if Artur is correct, but I disagree</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;From an implementation perspective, I have no guarantee that cross-origin resources would not be attacked in a cross-origin context</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Agreed, there is value in making the attacker perform the attack</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;In particular for size, if you can read measureMemory() API they can easily do that, and there&rsquo;s not much value in hiding it vs. having attackers perform it</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Surprised measureMemory() can read more than the JS heap</span></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Raised this concern yesterday, and we will not be implementing the JS profiling API, so these precedents are not valid for us</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;In my view, it&#39;s unclear what we would tell developers they would need to do in what resources they can set CORP to beyond just public resources that expose nothing confidential or network information.</span></li><li class="c2"><span class="c3">... Anything beyond that is something tricky and subtle and something they may get wrong.</span></li><li class="c2"><span class="c3">... Mike do you have a proposal for an opt-in for ...</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;It would be valuable for servers to have a signal that it is not a resource ever changed by the user requesting it. &nbsp;Not affected by cookies, IP, etc.</span></li><li class="c2"><span class="c3">... Seems like we would be able to do some things if we had an assertion from the server that a resource would never change based on the user requesting it</span></li><li class="c2"><span class="c3">... Not sure what all those changes would be</span></li><li class="c2"><span class="c3">... But a mechanism for the server to make this assertion, or the site has content that changes</span></li><li class="c2"><span class="c3">... I think that&#39;s a good idea apart from whether it gives any ability via timing and other proposals here</span></li><li class="c2"><span class="c3">... I wonder whether there are things we can do with caching and various levels of the stack if we had an assertion that this particular resource is never personalized</span></li><li class="c2"><span class="c3">... Servers could abuse this or there&#39;s some messaging potential</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Just unclear to me what the delta would be between this and CORP</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;CORP uses cookies</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;Could we have this an extension of CORP - credential-less mode?</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;My claim is if you accept there is a distinction between CORP and CORS, then there is a set of resources that can be included in your page, versus included+read. That latter group can be split about things that are user specific, but can be read across origins, where you need an ACAO header with a specific origin. </span></li><li class="c2"><span class="c3">&hellip; There&rsquo;s another kind that&rsquo;s not user specific. We have that in CORS with &nbsp;ACAO:* but it&rsquo;s hard to use, needs to be used in anonymous mode</span></li><li class="c2"><span class="c3">... If we reset expectations and set a flag that this is a public resource, that&rsquo;s a different category</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;In my slide here, if we had that magical mode today, you could put that instead of CORP here. It&rsquo;s just unclear to me what the difference is. </span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;For RUM providers, things like sizes is important to us from a pageweight PoV. We&rsquo;re reporting sizes on all of the content on our customers pages. It&rsquo;s not complete due to opt-in, so our assertions about page size are not accurate. If customers would be able to measure size for 3Ps, they&rsquo;d be able to better assess their page size</span></li><li class="c2"><span class="c3">&hellip; From a CDN pov, we could improve the network &hellip; but a lot of it is around page weight</span></li><li class="c2"><span class="c3">&hellip; status codes and content types can help us catch errors</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;visibility on type of resources? credentialed/user specific/etc?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;did a crawl and many resources include CORS, but no breakdown of types of resources. 25% TAO + 25% more with CORS</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;hard to know from the outside - application specific if the resource doesn something interesting with user data</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;From a developer perspective the difficulty about CORS is a) preflights and b) the fact that you can&rsquo;t opt-in all your resources to CORS and having to deal with the crossorigin attribute. I see the appeal in a &ldquo;not personalized&rdquo; kind of header, even if it overlaps with CORS.</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;The place I would like to get is a place where the defaults are different from where they are today. i.e. credentialed request mode is not enabled by default.</span></li><li class="c2"><span class="c3">... Changing that default would give us different characteristics on the web than what we see today</span></li><li class="c2"><span>... And some kinds of </span><span>requests are easier</span><span>&nbsp;to reason about. &nbsp;People using IP addresses for ACLs and intranets would still be an issue. But it would help if resources using credentials </span><span>became</span><span class="c3">&nbsp;more rare.</span></li><li class="c2"><span class="c3">&hellip; That comes in two steps: introduce a new COEP: &ldquo;don&rsquo;t send my credentials&rdquo;. We could then introduce a server side header indicating that the resource is not personalized. But that&rsquo;s not yet spelled out.</span></li><li class="c2"><span class="c1">Artur:</span><span class="c3">&nbsp;I am still hung up on the distinction between the mode that would replace CORP (credential-less mode), this is exactly what CORP was meant to do. &nbsp;Only difference is semantic where CORP cross-origin I allow a resource to be read in isolated contexts.</span></li><li class="c2"><span class="c3">... To me CORP cross-origin encompass already what you are talking about</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;That could be the case. &nbsp;I&#39;m willing to be convinced that this distinction is not one that makes any difference, and that it&rsquo;s not worth trying to introduce complexity around those concepts. Not what I had in mind when we were designing these.</span></li><li class="c2"><span class="c3">... Seems to me in the status quo there are resources that want to change the content by user, but do not want that content to be exposed to the embedder</span></li><li class="c2"><span class="c3">... That might not be possible and we&rsquo;d have to align the web&rsquo;s API surface to that. But I&rsquo;m not quite willing to give that up yet.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;What concerns me about drawing that line is that people may trip over it and fall and break their face</span></li><li class="c2"><span class="c3">... In my view it&#39;s better to have a line that splits personalized vs. non-personalized than a more subtle one</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Part of the line I think might be worth holding is whether the content may be legible. Artur may have more context as he&rsquo;s dealing with resource Google sets CORP on. If it&#39;s the case for all of those resources we would also be comfortable using CORS across origins, that&rsquo;s a strong argument towards the stance that we shouldn&rsquo;t make a distinction.</span></li><li class="c2"><span class="c1">Artur:</span><span class="c3">&nbsp;I think it is, but it&#39;s conflated by how I&#39;ve been thinking about CORP is where we roll it out</span></li><li class="c2"><span class="c3">... If we were to set CORP cross-origin on a resource that has authenticated information, we would treat this as a vulnerability, because it could end up in someone else&rsquo;s process.</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;One point that might make this more complicated is that in Chrome we have the ability to load IFRAMEs out of process, where that may not be in other browsers</span></li><li class="c2"><span class="c3">... We require you to set CORP in isolated contexts. Not clear to me that every resource that wants to be embedded in a page also wants to be read by its embedder</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;For example on Android iframes are not necessarily in a different process</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;Browsers are not yet at a point where out-of-process iframes are universal. In that world there are HTML documents that would not want to be legible to their embedder yet want to be embedded. That&rsquo;s a line we want to hold, or otherwise, we need to change some iframes.</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;That nore an issue implementation problem issue of cross-origin isolated and what it includes</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;It&rsquo;s an implementation problem, but will be us for a while</span></li><li class="c2"><span class="c1">Camille:</span><span class="c3">&nbsp;If you want to be embedded in a context where you won&#39;t be legible, you don&rsquo;t set COEP on yourself, so you&rsquo;d still be able to be embedded across-origin.</span></li><li class="c2"><span class="c1">Mike:</span><span class="c3">&nbsp;We&#39;re over time, what&#39;s the right place to continue this discussion</span></li><li class="c2"><span class="c1">Yoav:</span><span>&nbsp;I&#39;ll create a new issue on ResourceTiming and do my best to summarize this issue</span><sup><a href="#cmnt2" id="cmnt_ref2">[b]</a></sup></li><li class="c2"><span class="c1">Ryosuke:</span><span class="c3">&nbsp;Want to echo the point that we have to hold the line that resources may want to be embedded but not read. &nbsp;We&#39;ve been thinking about this. &nbsp;Hardest ones are scripts. &nbsp;For images other than size don&#39;t need to be readable via CORP.</span></li><li class="c2"><span class="c3">... Some assumptions discussed here are not all agreed upon by browsers</span></li></ul><h3 class="c5" id="h.6na6dc1pssqh"><span class="c11"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1MemLql-PMYyCnNKnicU9SPLwP55dhIwfe5UVFwEH5GM/edit?usp%3Dsharing&amp;sa=D&amp;ust=1607595378445000&amp;usg=AOvVaw2N4Ees5OazsA4eoVqmr2qv">Reporting API updates</a></span><span class="c24">&nbsp;- Ian Clelland</span></h3><ul class="c7 lst-kix_vyc1ggokfshl-0 start"><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;currently Chrome is the only implementer</span></li><li class="c2"><span>&hellip; support for </span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 257.33px;"><img alt="" src="images/image15.png" style="width: 624.00px; height: 257.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">&hellip; reporting API has been split into Reporting and Network Reporting</span></li><li class="c2"><span class="c3">&hellip; different scopes, data and privacy implications</span></li><li class="c2"><span class="c3">&hellip; Spun off crash, deprecation and interventions reports to their own documents</span></li><li class="c2"><span class="c3">&hellip; the Reporting API defines structure, report format, end points. Defines reports that are tied to the lifetime of the Document. Also defined ReportingObserver</span></li><li class="c2"><span class="c3">&hellip; Recently added worker support, credentials no longer sent across-origins, updates to relative URL handling</span></li><li class="c2"><span class="c3">&hellip; Network Reporting API - covers out-of-band reporting, like NEL</span></li><li class="c2"><span class="c3">&hellip; includes endpoint groups for improved reliability</span></li><li class="c2"><span class="c3">&hellip; Previously report-to couldn&rsquo;t been used as an identifier, so we moved it to an origin level opt-in - Origin Policy</span></li><li class="c2"><span class="c3">&hellip; Also, defined as infrastructure without any report types</span></li><li class="c2"><span>Open issues </span><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 542.00px; height: 196.00px;"><img alt="" src="images/image1.png" style="width: 542.00px; height: 196.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Just as a reminder, the reasoning for splitting up the previous reporting API into 2 separate infrastructure specs was that Mozilla was interested in implementing one but not the other</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Roughly matches my understanding, they wanted reporting for COOP/COEP, but not interested in reporting beyond the document</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;On the Origin Policy front, any movement? Saw open issues regarding the performance implications of Origin Policy dependencies that from the network reporting perspective may not be awful.</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Probably not as bad. The 2 biggest issues I recall is the first load problem, and concerns around the Origin Policy itself being a cookie-like mechanism. What we need for network reporting is some sort of origin-level configuration, where Origin Policy seems like a good candidate for that, but it may not be the only one. </span></li><li class="c2"><span class="c3">&hellip; We could tie it to DNS/SRV records</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;That would introduce operational complexity</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Interested in what other implementers think</span></li><li class="c2"><span class="c1">Sean:</span><span class="c3">&nbsp;Not too sure about Mozilla. Need to check</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;No strong feelings, but haven&rsquo;t followed it closely enough</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;For the privacy issues, should we take it to the privacy CG?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Normally, we tackle issues internally until we think the privacy story looks good. Can involve privacy oriented folks in those discussions. So can bring in folks from the Privacy CG to review bits and pieces</span></li><li class="c2"><span class="c1">Carine:</span><span class="c3">&nbsp;Privacy is part of wide review, but maybe we can meet with them and get ideas</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;wide-review is rather late, but we can kick off an earlier one with the PING</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;the capability URLs point seem more boolean than the user control one. Seems like we don&rsquo;t want reports to maintain state beyond cookies, and if they do we should fix it. The user control question seems like something more opinionated, with various right answers depending on the UA and the user&rsquo;s opinions.</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;I&rsquo;d prefer to leave that to implementers and there&rsquo;s room for different browsers to have different opinions, but there are people who disagree.</span></li><li class="c2"><span class="c3">...On the capability URL front, the browser cannot prevent capability URLs from leaking other than advising site owners against doing that</span></li><li class="c2"><span class="c3">&hellip; The risk is exposing the actual URLs in reports that get shared with 3P (e.g. login session identifiers, change password, etc)</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;One way to tackle it is to expose only a part of the actual URL and only expose hashes to enable the first party find the URL through URL to hash mapping.</span></li><li class="c2"><span class="c1">Alex:</span><span class="c3">&nbsp;the game of guessing which parts of URLs are sensitive is a losing game. We should stick to &ldquo;any portion of a url is sensitive and can be used to steal information&rdquo;.</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Probably true in the generic case</span></li></ul><p class="c9 c30"><span class="c3"></span></p><h3 class="c5" id="h.n569ki9kzyv2"><span class="c11 c1"><a class="c4" href="https://www.google.com/url?q=https://docs.google.com/presentation/d/1Wu2hK3SKKE9mMgFULLZV7u17XGe862-ZXPBvzayUZ_s/edit%23slide%3Did.p&amp;sa=D&amp;ust=1607595378453000&amp;usg=AOvVaw34560qeqdisOjtUjZ7x_Cn">Reporting API and performance metrics</a></span><span class="c24">&nbsp;- Yoav Weiss</span></h3><ul class="c7 lst-kix_nf99afexz4qg-0 start"><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Today we suggest developers and analytics to use page visibility data to send beacons before the user leaves</span></li><li class="c2"><span class="c3">... Existing events such as pageshow, pagehide, beforeunload, unload are not reliable hooks to ensure data can be sent</span></li><li class="c2"><span class="c3">... Visibility events are an unintuitive proxy for &quot;send your beacons here&quot;</span></li><li class="c2"><span class="c3">... Requires backend stitching for everything beyond the first visibility session</span></li><li class="c2"><span class="c3">... Still not common, skewed reporting for continuous metrics</span></li><li class="c2"><span class="c3">... Many reports are biased towards &quot;onload&quot; time or other early stages in page lifecycle</span></li><li class="c2"><span class="c3">... Target use case: &quot;I wish I could just tell browser the metrics I want to collect and send it when tab is gone&quot;</span></li><li class="c2"><span class="c3">... Using Reporting API</span></li><li class="c2"><span class="c3">... Non-goal: I wish there was a way to collect known metrics without running scripts</span></li><li class="c2"><span class="c3">... Rough sketch:</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 348.00px;"><img alt="" src="images/image12.png" style="width: 624.00px; height: 348.00px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c3">... Developer has a blog of various metrics, an endpoint and timeout (so reports don&#39;t lag too much)</span></li><li class="c2"><span class="c3">... Register report</span></li><li class="c2"><span class="c3">... Later-on, the user can add metrics to the blob</span></li><li class="c2"><span class="c3">... Report send by browser when timeout expires or renderer dies</span></li><li class="c2"><span class="c3">... Interesting?</span></li><li class="c2"><span class="c3">... Slightly better ergonomics?</span></li><li class="c2"><span class="c1">Steven:</span><span class="c3">&nbsp;I don&#39;t think we would switch because today we send a beacon, SPA, we send one payload per SPA page transition. &nbsp;Doing at the end of the session would be hours of data.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;What do you do for cases where the user goes away?</span></li><li class="c2"><span class="c1">Steven:</span><span class="c3">&nbsp;We implemented our own version of TTI, wait for activity to die down, send a beacon once that is reached. &nbsp;We don&#39;t wait for visibility change.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;Makes sense for a long-lived SPA, so a problem around cutting up sessions in a load. &nbsp;Even around one route or soft-nav, you may want to send out a report early. &nbsp;Isn&#39;t it true you&#39;d want to have a summary at the end of that.</span></li><li class="c2"><span class="c3">... With this proposal, you would send as late as possible with as much data as possible. </span></li><li class="c2"><span class="c3">Is the backend stitching work just something that hasn&rsquo;t happened yet, or something more fundamental?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;I can talk of our use cases, but wonder - &nbsp;if this type of API would enable you to send the data either now, after a timeout or when the page unload, then you kinda get the best of all worlds where you can accumulate it as long as you want, but if you need to force it out due to soft navigation you could. </span></li><li class="c2"><span class="c3">&hellip; We are constantly struggling between capturing as much data as we can and sending it out right away. Want to send right away due to both past reliability issues as well as for real-time reporting. That contradicts with collection not-just-loading data: JS errors, frame rates, and other continuous metrics.</span></li><li class="c2"><span class="c3">&hellip; Today we send the majority of the data around onload, but there is data we want to collect later. If we had a guarantee that we can send all that data in a single beacon, we wouldn&rsquo;t send it at onload, but later, when we have more data.</span></li><li class="c2"><span class="c3">&hellip; It kinda like an improvement to beacon, where we want to pile up more data and have the browser handle the transport. Would be very useful for us from a reliability point of view, and would enable us to be less load-focused.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Will you use it and if so, when?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;We would probably migrate to that straight away once available, as it would give some customers more data and improve its reliability and accuracy</span></li><li class="c2"><span class="c3">&hellip; Would definitely be a priority to use it right away</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;The reporting APIs try to coalesce reports when possible and delay them to save user bandwidth. I heard you want to send immediately. We would in that case give the ability to snapshot the data.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;in the model that I had in mind, you still have the object, so you can always cancel the report and sendBeacon it if you need to force data out.</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Would it be important to force it out, and would queueing be acceptable?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;We would like to guarantee real-timeness of the data. So waiting ~ minutes would hurt that.</span></li><li class="c2"><span class="c1">Ian:</span><span class="c3">&nbsp;Currently wait a minute</span></li><li class="c2"><span class="c1">Scott:</span><span class="c3">&nbsp;This has come up when talking about task scheduling, so want to schedule analytics in an idle task, but want guarantee that the task would eventually run. Currently track the tasks manually as well as scheduling them, but want an option to guarantee they run e.g. on page hide. So considering an option to postTasks that tells you when those tasks need to run. That gives you the best of both worlds: run if there&rsquo;s nothing else, but not interfere with user input and make sure it runs when user visibility changed. Do we need something generic for that?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Report sending doesn&rsquo;t have to happen on main thread.</span></li><li class="c2"><span class="c3">&nbsp;&hellip; Bits that could be interesting for scheduling pieces is metric collection. Would be good to coordinate those efforts</span></li><li class="c2"><span class="c1">Gilles:</span><span class="c3">&nbsp;Isn&#39;t this a slightly-more-advanced sendBeacon?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Different in that you setup an empty blob, then fill in the data later</span></li><li class="c2"><span class="c3">... Gives you data reliability that you&#39;re render won&#39;t die without sending data</span></li><li class="c2"><span class="c1">Gilles:</span><span class="c3">&nbsp;Original intention of sendBeacon, have some control of timeouts for when it gets sent</span></li><li class="c2"><span class="c1">Noam:</span><span class="c3">&nbsp;This sounds that it may be more reliable than sendBeacon. &nbsp;Notion of sending last-minute telemetry data before the session ends. &nbsp;sendBeacon can be reliable if there is a certain threshold of concurrent requests.</span></li><li class="c2"><span class="c3">... If this could be a higher-guaranteed, it would be a nice option</span></li><li class="c2"><span class="c1">Gilles:</span><span class="c3">&nbsp;Was original intent of sendBeacon() that it always works, but when it was implemented it wasn&#39;t work in always cases</span></li><li class="c2"><span class="c3">... When it&#39;s actually implemented there are shortcomings</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Fundamental difference is there&#39;s something you can declare ahead of time, and the browser can prepare. &nbsp;Where sendBeacon() is something you call at the very last instance.</span></li><li class="c2"><span class="c1">Gilles:</span><span class="c3">&nbsp;But when if you&#39;re modifying this at the very last moment, may the data not make it?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Potentially, yeah</span></li><li class="c2"><span>Nicol&aacute;s</span><span class="c3">: From my perspective the main benefit is improving the reliability of sending data, for implementation, we would need to store this in the browser in case the renderer crashes. &nbsp;So it&#39;s different from any task the renderer wants to run.</span></li><li class="c2"><span class="c3">... We don&#39;t want to store arbitrary data for any arbitrary renderer</span></li><li class="c2"><span class="c3">... Also limiting by size can be important, because if what you&#39;re sending gets too big, it reduces the likeness of it succeeding.</span></li><li class="c2"><span class="c3">Open questions:</span></li><li class="c2"><span style="overflow: hidden; display: inline-block; margin: 0.00px 0.00px; border: 0.00px solid #000000; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px); width: 624.00px; height: 337.33px;"><img alt="" src="images/image19.png" style="width: 624.00px; height: 337.33px; margin-left: 0.00px; margin-top: 0.00px; transform: rotate(0.00rad) translateZ(0px); -webkit-transform: rotate(0.00rad) translateZ(0px);" title=""></span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;If there are multiple tabs all with queued reports, and the browser crashes, it will have to send all reports at once</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;If some of the concerns around real-time and sending requests earlier, you may still have folks sending some data at visibility changes.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;You don&#39;t even have to cancel it, you take metrics out of it that you send right away</span></li><li class="c2"><span class="c1">Steven:</span><span class="c3">&nbsp;If this API had a way of send reports now, so you add your data to that object, then if you could send it now, flush buffer, that would be great</span></li><li class="c2"><span class="c3">... In a long session, we could decide when to send it</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;And if a timeout is really what you want, a setTimeout that does that, and if that never happens, that&#39;s fine too</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Also wanted to ask if the concern around real-time and stitching data that comes later would prevent this</span></li><li class="c2"><span class="c1">Benjamin:</span><span class="c3">&nbsp;Can you walk through the workflow intended by server-side stitching</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;When collecting metrics, have a collection server that receives metrics, where they want to process individually and displayed. &nbsp;If you get multiple reports per session, one example is sending reports on vis state changes, and the user clicks back and forth and you want to report on that single session, then you need at the collecting server or processing pipeline to realize that report A and D are from the same session/user and they need to be stitched together for presentation purposes.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I&#39;m very interested in metrics after page load</span></li><li class="c2"><span class="c3">... If you want to track the average interaction cost or smoothness, you need to wait to get all of that data</span></li><li class="c2"><span class="c3">... This gets more and more complicated if you have things like BFCache</span></li><li class="c2"><span class="c3">... You may have an eager report and a late report, or you may have a trickle effect.</span></li><li class="c2"><span class="c3">... Summing up might be different per-metric, and there&rsquo;s a whole backend infra issue that doesn&rsquo;t align with how it&rsquo;s built today. Is that correct?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;yeah. Let&rsquo;s say you have a data point on PLT and CLS, there also metadata that goes along with each one of those. If we could group that all together in single DB row, that&rsquo;s way more efficient than having 10 rows with the same metadata but with different timestamps. So it becomes a data processing problem to have data points trickle. From an infra point of view, that&rsquo;s why we try to group all of our data and send it all at once.</span></li><li class="c2"><span class="c3">... A lot of that is outside the concerns of this API, but a lot of RUM analytics providers do the same thing, and it&rsquo;ll help on that front. Makes it easier to process.</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;How do you envision you using this API while still accommodating the real-time constraints? Early report and complete report?</span></li><li class="c2"><span class="c1">Nic:</span><span class="c3">&nbsp;Maybe classify types of data as real-time vs. continuous.</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I see that this could be appealing as a &ldquo;lazy sendBeacon&rdquo;. But we talked about the performance timeline to evolve to e.g. soft navs. If this was tied specifically to just the performance timeline, we might be able to help hook those two together. &nbsp;E.g. doing the report automatically every time a session cuts. </span></li><li class="c2"><span class="c3">&hellip; Is the intention to focus narrowly or will it be up to developers to manually send the reports?</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Haven&rsquo;t thought about that, but could be interesting to bake in.</span></li><li class="c2"><span class="c3">&hellip; We could define some notion of sessions where things get sent</span></li><li class="c2"><span class="c3">... Developer-driven and browser-driven sessions</span></li><li class="c2"><span class="c3">... Send this report any time the page goes hidden, or some navigation-y thing happens</span></li><li class="c2"><span class="c3">... We could bake into frameworks, e.g. with the new navigation API</span></li><li class="c2"><span class="c1">Michal:</span><span class="c3">&nbsp;I suspect you&#39;ll always want developers to slice in some manner</span></li><li class="c2"><span class="c3">... I can see the ability to be more eager in slicing and also having the ability to capture the full page lifecycle</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;Major open question, can we unite behind one true way of sending metrics</span></li><li class="c2"><span class="c3">Gilles Are you thinking of a standardized report format</span></li><li class="c2"><span class="c3">... Observe and report and decide which fields you want to get</span></li><li class="c2"><span class="c3">... Trend of new APIs like NEL where it&#39;s all done automatically</span></li><li class="c2"><span class="c1">Yoav:</span><span class="c3">&nbsp;I think you&#39;ll always need JavaScript to decide what to send</span></li><li class="c2"><span class="c3">... A predefined report format is something else than what we were proposing here</span></li></ul><div class="c50"><p class="c31"><a href="#cmnt_ref1" id="cmnt1">[a]</a><span class="c3">Yoav: Take AI to start dialog @yoav@yoav.ws</span></p><p class="c31"><span class="c3">_Assigned to Yoav Weiss_</span></p></div><div class="c50"><p class="c31"><a href="#cmnt_ref2" id="cmnt2">[b]</a><span class="c3">@yoav@yoav.ws AI</span></p></div></body></html>